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At  tower-equipped  airports,   the  controllers  in  the  tower  cab  are 
responsible  for  those  aspects  of  Airport  Surface  Traffic  Control 
(ASTC)  requiring  centralized  management:    issuing  clearances  for 
aircraft  to  land,  taxi,  or  take  off;  establishing  routing  patterns 
for  arriving  and  departing  aircraft  on  the  runway/taxiway  net- 
work so  as  to  minimize  delays;  sequencing  aircraft  movements 
on  runways  and  taxiways  and  at  critical  intersections  to  ensure 
safety;  and  controlling  the  movements  of  service  or  emergency 
vehicles  on  the  airport  surface.    Because  of  the  expertise  of  the 
controllers  and  pilots,  the  ASTC  system  has  worked  well  most 
of  the  time.    However,  the  unfortunate  incidents  at  Chicago-O'Hare 
(20  December  1972)  and  Boston-Logan  (31  July  1973)  have  pointed 
out  certain  deficiencies;  e.g.,  the  system's  surveillance  capability 
when  visibility  is  poor. 

Initiated  by  the  Federal  Aviation  Administration  (FAA),   the  ASTC 
program  is  in  the  process  of  implementing  several  near-term 
system  improvements.    However,  it  is  expected  that  these  improve- 
ments, while  adequate  for  the  1970's,  will  not  be  adequate  to  meet 
the  more  stringent  long-term  requirements  of  the  1980 's. 

The  approach  which  has  been  taken  in  the  present  study  is  to  con- 
centrate on  the  Nation's  most  active  and,  in  one  sense,  most 
mature  airport;  i.e.,  Chicago-O'Hare.    In  performing  the  study 
at  O'Hare,  the  cooperation  of  the  Airport  Traffic  Control  Tower, 
the  City  of  Chicago  Department  of  Aviation,  and  the  FAA  Great 
Lakes  Region  was  essential  to  the  success  of  the  effort.    Mr. 
Paul  S.  Rempfer,  of  the  Transportation  Systems  Center  (TSC), 
acted  as  technical  monitor  for  the  Government.    In  addition, 
Messrs.  Rempfer  and  L.  Stevenson,  also  of  TSC,  performed  the 
theoretical  analysis  of  local  area  capacity  which  is  presented  in 
Section  5.  3.  3. 1  of  Volume  III. 
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SECTION  1  -  INTRODUCTION 


1.1  OBJECTIVES 

General  criteria  for  an  ASTC  system  include  (1)  to  be  as  simple  and 
low  in  cost  as  possible  while  addressing  the  basic  objectives  and  (2)  to  be  equally 
applicable  to  all  airports  requiring  it,  which  could  be  quite  a  few.    The  basic 
system  objectives  fall  into  three  major  areas  of  control  as  follows: 

1.  Local  Control  -  To  provide  accurate  and  timely  information  to 
Local  Control  on  the  suitability  of  each  inter-arrival  space  for 

a  departure  release.    This  assistance  would  offer  benefits  which 
could  amount  to  a  20  percent  increase  in  departure  capacity  for 
the  more  difficult  to  handle  runway  configurations  with  good 
visibility  and  a  30  percent  increase  for  single  mixed  operations 
with  bad  cab  visibility.    Also,  Local  Control  must  be  provided 
with  positive  assurance  that  the  runway  on  which  he  is  about  to 
clear  an  operation  is,  in  fact,  clear  of  other  vehicles.    This 
latter  requirement  is  critical  to  the  basic  safety  of  operation. 

2.  Ground  Control  -  To  provide  the  location  and  identity  of  each 
vehicle  under  control  to  Ground  Control  to  reduce  the  excessive 
communications  (work)  load  due  to  position  reporting  under  bad 
visibility  conditions.    The  average  content  of  voice  communi- 
cations for  Ground  Control,  indicates  that  these  position  reports 
represent  85  percent  of  the  increased  channel  loading  experienced 
under  bad  cab  visibility.     The  identity  could  assist  Ground  Control 
in  maintaining  vehicle/identity  correlation  in  good  visibility. 

3.  Ramp  Control  -    To  provide  a  centralized  system  of  ramp  entry 
clearance  to  permit  the  most  efficient  use  of  those  ramp  areas 
which  can  only  support  one-way  traffic  flow.    This  implies 
operation  in  a  batch  or  platoon  mode  (e.g. ,  multiple  "pushbacks" 
and  taxiing  aircraft  within  a  ramp  area). 

The  first  two  objectives  are  basically  information  presentation  (sur- 
veillance) problems.    In  light  of  criteria  (1),  the  initial  ASTC  concept  will  be 
surveillance  only,  without  control  automation.    In  addition,  automation  of  control 
functions  would  make  it  much  more  difficult  to  maintain  equipment  commonality 
between  airports.    While  the  basic  information  needs  at  different  airports  may  be 


the  same,  the  control  problems,  especially  for  an  automated  Ground  Control 
System,  can  be  quite  different. 

The  third  problem  is  quite  different  from  the  first  two.    There  is 
currently  no  centralized  ramp  control.    The  FAA  is  not  responsible  for  the  ramp 
area;  there  is  no  such  control  position.    Staffing  constraints  and  room  in  the  cab 
make  addition  of  a  position  undesirable.    Such  a  system  would  have  to  be  heavily 
automated  and  managed  by  the  current  complement  of  controllers,  primarily 
Clearance  Delivery.    This  automation  would  probably  require  the  substantial 
tailoring  of  equipment  to  each  airport.    In  addition,  the  participation  of  airline 
operations  personnel  would  be  required  in  the  system  and  scheduling  of  pushbacks 
(a  controversial  item  at  best)  would  be  involved. 

The  above  considerations  motivate  the  Tower  Automated  Ground 
Surveillance  (TAGS)  concept.    TAGS  is  basically  a  surveillance  system  aimed  at 
problems  1  and  2  above.    Information  retrieval,  processing,  formatting  and 
display  are  automated.    Control  functions  remain  in  the  hands  of  the  controllers. 
It  is  a  simple  system  (conceptually),  addressing  the  basic  problems  and  permitting 
inter-airport  equipment  commonality.    In  the  remainder  of  the  report  TAGS  is 
described  in  terms  of  subsystems  covering  its  major  areas;  a  Local  Control 
System  (LCS)  and  a  Ground  Control  System  (GCS).    In  addition,  to  provide  an 
understanding  of  what  could  be  offered  in  the  ramps,  a  Ramp  Control  System  (RCS) 
is  also  described.    Because  of  the  problems  enumerated  above,  RCS  is  considered 
an  option  and  is  not  intended  as  part  of  the  initial  TAGS  development. 

The  results  of  this  working  paper  are  expected  to  be  used  in  the  further 
development  of  concepts  for  each  of  the  three  major  systems.    Preliminary  discus- 
sions of  the  system  concepts  are  provided  in  this  document  in  order  to  show  how 
the  requirements  are  related  to  the  concept  currently  under  development.    It  is 


expected  that  refinements  to  the  requirements  established  in  this  working  paper 
will  take  place  as  they  are  compared  with  the  capabilities  that  can  be  achieved 
through  various  surveillance  sensor  techniques  and/or  data  transfer  methods.    As 
such,  therefore,  they  should  be  taken  as  representing  a  "first  cut"  in  establishing 
the  information  required  by  the  controller  and  the  estimated  performance  require- 
ments of  the  surveillance  sensors  that  will  serve  to  collect  this  information. 

In  performing  this  concept  development,  the  system  designer  is  faced 
with  the  problem  of  attempting  to  replace  the  information  gathering  capabilities  of 
a  visual  surveillance  method  with  other  display  or  information  presentation  methods 
wherein  the  man/machine  information  transfer  process  will  be  completely  different 
from  that  provided  by  visual  means.     Because  of  this,  the  design  philosophy  employed 
in  the  concept  development  process  has  been  one  wherein  emphasis  is  placed  on  the 
use  of  data  processing  techniques  as  far  as  possible  to  perform  as  many  portions  of 
the  control  functions  as  possible;  the  basic  premise,  however,   is  that  the  control 
decisions  will  be  made  by  the  controller  and  not  by  the  machine.     Under  this  philos- 
ophy emphasis  is  placed  upon  the  real-time,   semi-automatic  aspects  of  the  control 
process  wherein  the  information  presented  to  the  controller  is  specifically  related 
to  the  function  he  is  performing  at  a  given  time.    Without  this  selectivity,   it  is  be- 
lieved that  the  controller's  ability  to  perform  the  required  functions  at  normal  op- 
erational levels  will  be  seriously  hampered. 

Another  common  aspect  of  the  three  portions  of  the  ASTC  system  would 
be  the  use  of  data  processing  capabilities  for  controller  cueing,   or  scheduling,  of  the 
functions  he  is  to  perform.    This  capability,   of  course,  would  be  overridden  by  the 
controller  when  necessary. 

The  methodology  employed  to  establish  the  several  types  of  require- 
ments is  discussed  later  in  this  section;  it  essentially  relies  on  the  examination  of 
aircraft  movement  profiles  and  the  control  actions  currently  employed  by  the  cab 
controllers.    The  functions  performed  in  each  of  the  three  major  systems  have  been 
derived  as  a  result  of  careful  and  extensive  study  of  cab  operations  at  the  busiest 


commercial  airport  in  the  world,  namely,  O'Hare  Field.  It  is  recognized  that  at 
some  other  major  airports  all  of  the  functions  described  in  this  report  may  not  be 
necessary,  and  that  in  some  cases  other  functions  may  be  required.  However,  in 
our  judgment  these  changes  will  be  minor. 

For  each  of  the  three  systems  the  functions  to  be  performed  are  de- 
scribed.    The  information  transfer  aspects  of  each  function  are  examined  and  these 
are  then  translated  into  the  performance  requirements  desired  of  the  surveillance 
sensors.    To  determine  the  total  load  on  the  three  systems,   airport  operational 
levels  are  estimated  both  during  the  busy  hour  as  well  as  for  short-term  peaks. 
This  operational  requirement  will  impact  on  the  data  rates  at  various  portions  of 
the  several  systems  and  will,  for  example,  be  used  in  establishing  surveillance 
sensor  update  rates,    "refresh"  rates  of  displays,  etc. 

A  basic  constraint  used  in  the  development  of  the  three  systems  has 
been  the  reliance  on  voice  rather  than  data  link  between  the  pilot  and  the  controller. 
The  availability  of  automated  communications  between  these  two  individuals  can,  in 
the  future,  lead  to  the  evoluation  of  a  more  fully  automated  system  from  the  con- 
cepts presented  in  this  and  subsequent  documents. 

In  addition  to  investigating  the  three  major  systems  described  above, 
further  material  is  presented  on  two  other  concepts  which  will  impact  on  the  Ramp 
Control  System  and  Ground  Control  System,   respectively.     In  the  first  area  an 
Automatic  Gate  Status  Equipment  is  included  as  part  of  the  Ramp  Control  System. 
This  subsystem  could  be  expected  to  provide  benefits  to  the  airline  operators  by 
itself,  and  at  some  airports  may  be  desirable  as  a  separate  module  even  though  an 
automated  or  semi-automated  Ramp  Control  System  is  not  implemented. 

With  respect  to  the  control  functions  performed  as  part  of  the  GCS,  a 
separate  examination  was  made  of  potential  benefits  of  a  so-called  STR  (standard 
taxiway  routing)  module.     This  particular  aspect  is  treated  separately  from  the 
Ground  Control  System  which,  of  course,  does  include  as  one  of  its  functions  that 
of  Routing  Control. 


1.2  CHARACTERISTICS  OF  REQUIREMENTS 

The  establishment  of  system  requirements  is  a  complex  process  involv- 
ing tradeoffs  between  design  concepts,   economics,   and  operational  constraints. 
The  conventional  starting  point  is  usually  that  of  defining  the  problem(s)  by  means 
of  a  series  of  data  collection  experiments,  or  operations  analysis.    While  many 
valuable  inputs  to  the  requirements  establishment  process  are  obtained  in  this 
manner,   it  should  be  recognized  that  an  existing  system  or  procedure  in  itself 
imposes  constraints  or  limitations  which  a  new  system  concept  may  not  have  to 
contend  with. 

The  requirements  to  be  set  forth  in  this  document  are  preliminary  in 
nature;  it  is  expected  that  system  (module)  synthesis  efforts  to  be  performed  later 
in  this  program  will  result  in  some  modification  to  the  qualitative  and  quantitative 
values  given  in  this  report.  We  shall  consider  requirements  as  comprising  three 
areas,  namely  Functional,  Operational,  and  Performance  requirements  as  defined 
below. 

Functional  requirements  may  be  defined  as  those  describing  the  tasks 
which  a  system  or  module  is  to  accomplish.     They  answer  the  question  'What  must 
the  system  do?"  and  as  such  are  a  mixture  of  qualitative  and  quantitative  state- 
ments.    Representative  examples  of  functional  requirements  include: 

•  Release  of  an  aircraft  for  takeoff  (or  taxiing} 

•  Clearance  for  runway  crossing 

•  Providing  route  information 

Identification  of  system  (subsystem)  users  and  their  characteristics 
will  also  be  considered  as  part  of  the  Functional  Requirements  definition.     In  most 
cases  the  primary  users  of  the  system  are  the  controller (s)  and  the  pilots;  however, 
other  potential  users  (or  data  sources)  will  be  involved  in  the  information  flow  proc- 
ess.    A  preliminary  list  of  potential  system  users  and/or  personnel  who  may  inter- 
face with  the  TAGS  system  is  given  in  Table  1-1. 


Table  1-1.    Identification  of  Potential  System  Users 


FAA  -  CAB 

Flight  Data 

Clearance  Delivery 

Outbound  Ground  Control 

Inbound  Ground  Control 

North  Local  Control 

South  Local  Control 

Watch  Supervisor 

TRACON 

Approach  Control  -  North 

Approach  Control  -  South 

Departure  Control  -  North 

Departure  Control  -  South 

Monitor  Control 

Airlines 

Pilot 

Personnel 

Ramp  Area 

Gate  Attendant 

Cargo  Supervisor 

Tow  Vehicle  Operator 

Ramp  Supervisor  (Gate  Manager) 

Ramp  Controller  (Tower) 

Airport 

Vehicle  Operator 

Duty  Supervisor 

To  meet  the  Functional  Requirements,  the  subsystem  work  flow  may- 
be considered  as  comprising  machine-type  process  and  human  efforts.    We  shall 
attempt  to  use  the  term  "job"  to  describe  machine-type  process  and  the  term 
"task"  to  describe  those  functions  performed  by  the  controller,  pilot,   etc.     Pre- 
sentation of  data,  via  a  display,  to  the  controller  is  therefore  a  "job"  of  the  partic- 
ular subsystem,  while  the  interpretation  of  this  data,   as  well  as  the  voice  commun- 
ication process  represent  "tasks"  performed  by  the  controller. 

Operational  requirements  represent  parameters  relating  to  the  total 
situation  under  which  the  functional  requirements  are  to  be  met.     They  include 
traffic  considerations  (load);  environmental  (weather)  aspects;  facility  constraints 
(runway  configurations,   ramp  areas,  etc.  );  and  the  operational  procedures  and 
standards  imposed  for  safety  reasons.     Representative  examples  of  operational 
requirements  include: 

•  Number  of  active  aircraft  in  a  particular  geographic  area  at  one 
time  or  during  a  particular  interval  of  time 

•  Visibility  level 

•  Separation  standards 

Performance  requirements  are  a  quantitative  estimate  of  the  acceptable 
capabilities  of  the  module  and  its  components  required  to  meet  the  applicable  func- 
tional and  operational  requirements.     These  are  expected  to  vary  in  different  por- 
tions of  the  TAGS  system,   i.  e.  ,  the  required  position  accuracy  may  be  different 
in  the  ramp  area  as  contrasted  with  the  final  approach  area.     Typical  examples  of 
performance  requirements  include: 

•  Data  Rates /Response  Times 

•  Accuracy  of  Position  and/or  Velocity  Data 

•  Resolution 


1.3  METHODOLOGY 

1.3.  1  General 

The  methodology  employed  to  develop  the  ASTC  (TAGS)  performance 
requirements  has  been  based  upon  a  detailed  examination  of  mission  profiles  (or 
scenarios).     These  scenarios  are  comprised  of  three  major  components,  namely 

Aircraft  Movement  Profile 

Pilot  Functions 

Control  System  Functions 

The  information  flow  between  the  major  components  of  the  ASTC  sys- 
tem is  illustrated  in  Figure  1-1;  the  characteristics  of  these  components  will,  of 
course,  be  different  for  the  Ramp  Control,   Ground  Control,  and  Local  Control 

Systems. 

The  Aircraft  Movement  Profile  component  includes  both  aircraft  pa- 
rameters/constraints, as  well  as  airfield/airspace  characteristics.  As  represen- 
tative of  the  former,  one  must  consider  aircraft  equipment  types,  braking  capabili- 
ties, etc.;  the  latter  area  essentially  describes  the  characteristics  of  the  facilities 
(taxiways,  runways,  etc. )  that  can  be  considered  as  providing  "service"  to  the  air- 
craft. 

Functions  expected  to  be  performed  by  the  pilot  in  the  semi- automated 
system  are  listed  in  Table  1-2.  These  functions  are  relatively  independent  of  the 
particular  control  system  involved. 

The  Control  Functions  will  be  examined  in  detail  for  each  of  the  three 
major  subsystems.     This  investigation  will  consider  first  the  estimated  Data  Re- 
quirements needed  either  by  the  Controller  or  a  computer  to  adequately  perform 
the  Control  System  Functions.     It  is  in  this  area  that  consideration  must  ultimately 
be  given  to  man/machine  interface  or  display  characteristics. 


Table  1-2.    Pilot  Functions 


Maintain  separation  from  preceding  aircraft  on 
same  link  or  "highway". 

Determine  partial  identity  (aircraft  equipment  type 
and  airline)  of  nearby  aircraft. 

Maintain  aircraft  speed  below  safe  limits  consistent 
with  taxi  way  constraints  and  flight  phase. 

Navigate  aircraft  using  VGE  references  and  aircraft 
instruments. 

Maintain  lateral  (center line)  control. 

Select  appropriate  R/W  turnoff. 

Stop  aircraft  clear  of  intersections,  obey  runway 
crossing  hold  lines. 

Provide  controller  with  aircraft  status  data  as  needed 
i.e.,  Ready-to-Taxi,  Position  Report,  etc. 


Inputs  to  the  system  Data  Base — from  which  the  control  data  is  de- 
rived— will  be  classified  as  Information  Elements.    These  fall  into  two  classes: 
Real  Time  (or  sensor-derived)  data  and  Support  data.     The  characteristics  of  the 
required  Sensor  or  Real  Time  Information  Elements  are  those  of  primary  interest. 

The  communication  processes  for  a  semi-automated  system  may  use 
present-day  voice  techniques  or  signaling  methods  which,  for  example,  utilize 
FGE  facilities,  or  possibly  existing  capabilities  in  the  cockpit.     Of  major  interest 
insofar  as  the  communications  portion  of  the  control  process  is  concerned    is  the 
System  Response  Time  discussed  in  the  next  paragraph. 


1.3.2 


System  Response  Time  Considerations 


The  major  response  time  factors  to  be  considered  for  a  semi-auto- 
mated surface  traffic  control  system  include 


Sensor  Response  Time  Variable 

Conflict  Recognition  (Detection)  Interval  1.5-3  sec. 

Conflict  Resolution  Time  1-2  sec. 

Communication  Duration  (Controller-Pilot)  5-6  sec. 

Aircraft  Dynamics  (including  Pilot  Response  Time)  5.  5-8  sec. 

Preliminary  values  have  been  assigned  to  these  various  components  of 
response  time  based  upon  rationale  given  below. 

The  Conflict  Recognition  process  would  be  performed  by  a  computer 
with  negligible  time  delay.     However,  presentation  of  the  results  to  the  controller 
via  some  type  of  display,  plus  his  interpretation  of  the  display,  will  take  a  small 
amount  of  time.     Moreover,   it  is  expected  that  multiple  conflicts  may  result  in  de- 
lay in  the  presentation  of  a  small  number  of  cases.     These  factors  had  led  to  an 
estimate  of  from  1.  5  seconds  to  3  seconds  for  this  process. 

The  Conflict  Resolution  process  is  that  wherein  the  Controller  makes 
the  decision  to  prevent  the  upcoming  conflict.  This  decision,  which  may  involve 
holding  or  sequencing  an  aircraft,  may  overlap  the  Conflict  Recognition  process. 
Time  estimates  of  1  second  to  2  seconds  have  been  used  for  this  process. 

Communications  transactions  (CT)  between  pilots  and  controllers  aver- 
age about  8  seconds  to  9  seconds  in  duration.     Control  or  decision-type  CTs  are 
expected  to  be  shorter.     Based  upon  voice  communications  this  parameter  has  been 
estimated  at  from  5  seconds  to  6  seconds. 

The  implementation  by  the  pilot  of  a  control  instruction  will  be  con- 
strained by  the  pilot  response  time  (0.  5  second  to  1.  0  second)    as  well  as  the  dynam- 
ics of  the  aircraft.    At  normal  taxiing  speeds  it  is  estimated  that  5  seconds  to  7 
seconds  may  be  required  for  a  normal  aircraft  "stop". 

The  sum  of  the  above  factors  ranges  from  13  seconds  to  19  seconds. 
Sensor  response  times  of  from  1  second  to  2  seconds  represent  durations  which 
would  not  unduly  penalize  the  overall  system  response  time.     This  range  of 


intervals  permits  the  recognition  of  the  various  events  to  be  handled  in  the  control 
process,    i.  e. ,  recognition  of  the  time  an  aircraft  enters  the  taxi  system  or  new 
link. 

These  components  of  response  time  require  of  course  further  study  of 
man/machine  relationships  in  the  actual  system  and  represent,  therefore,  only 
very  preliminary  values.    The  limiting  factors  of  voice  communications  and  air- 
craft dynamics  are  readily  apparent  in  the  breakdown  given  above. 

It  is  envisioned  that  the  conflict  estimation  process  to  be  performed  by 
the  computer  would  be  organized  so  that  several  levels  of  potential  conflict  are  de- 
fined based  upon  the  prediction  interval.  For  example,  top  priority  would  be  given 
to  prediction  intervals  of  say  15  seconds  to  22.  5  seconds,  second  priority  to  con- 
flicts expected  to  occur  in  time  intervals  of  22.  5  seconds  to  30  seconds  in  the  future 
and  lowest  priority  to  a  time  interval  of  30  seconds  to  45  seconds.  An  example  of 
the  latter  might  be  the  prediction  of  an  "Arrival"  at  the  ramp  entrance  point. 


SECTION  2  -  COMPOSITE  AIRPORT  SURFACE  TRAFFIC 
CONTROL  SYSTEM  OPTIONS 


The  integration  of  the  three  major  systems  into  a  composite  ASTC 
system  for  a  specific  airport  can  result  in  a  wide  variety  of  hardware  config- 
urations.   These  configurations  will  be  influenced  by  the  airport  layout,  capa- 
bilities of  existing  hardware,  weather  considerations,  etc.    In  some  cases,   it 
may  be  desirable  to  provde  semi-automation  capabilities  for  only  some  of  the 
functions  performed  in  one  of  the  three  major  areas.    For  example,  a  subsys- 
tem providing  R/W  crossing  management  might  be  a  desirable  feature  at  an 
airport  having  visibility  constraints  but  not  requiring  automation  of  other  Ground 
Control  functions.    It  is  not  the  purpose  of  this  document  to  put  together  all  the 
possible  means  by  which  composite  ASTC  systems  can  be  designed  for  a  spe- 
cific airport  from  the  building  blocks  or  systems  described  herein.    The  rationale 
by  which  the  performance  requirements  are  developed  for  each  of  the  three  sys- 
tems can  be  used  by  the  system  designer  to  tailor  a  particular  configuration 
meeting  the  needs  of  a  specific  airport.    Later  in  this  report  a  composite  list 
of  system  performance  requirements  is  developed  based  upon  those  established 
for  each  of  the  three  separate  systems.    In  some  cases,  therefore,  only  the 
performance  requirements  needed  for  one  of  the  three  systems  might  have  to 
be  specified  for  a  given  installation. 

It  is  expected  as  more  detailed  design  of  the  total  ASTC  concept  is 
accomplished,  specific  recommendations  for  utilizing  existing  data  processing 
hardware,  centralizing  data  bases,  etc.  can  be  developed.    These  interface 
and  specific  airport- related  aspects  of  the  ASTC  design  are  beyond  the  scope 
of  the  current  study. 


SECTION  3  -  DEVELOPMENT  OF  A  RAMP  CONTROL 
SYSTEM  (RCS)  CONCEPT) 

3. 1  INTRODUCTION 

This  section  investigates  the  possibility  of  an  automated  Ramp  Control 
System.  It  is  intended  to  show  what  might  be  done  in  the  ramp  area.  As  stated  in 
the  introduction,  RCS  is  considered  an  optional  subsystem  of  TAGS  and  will  not  be 
a  part  of  the  initial  TAGS  development. 

The  development  of  the  Ramp  Control  System  (RCS)  (module)  concept 
is  directed  toward  improvement  of  the  processes  for  coordination  and  control  of 
operations  in  the  ramp  area(s)  of  the  airport  and  for  coordination  of  these  opera- 
tions with  other  airport  surface  traffic  control  operations.    The  development  of  the 
concept  is  based  upon  the  integration  of: 

©  Improved  techniques  of  information  exchange  between  the  airport 

traffic  control  tower  (ATCT),  airline  operations,  and  automated 
enroute  and  terminal  ATC  systems. 

e  Established  basic  procedures  for  flight  operations  coordination. 

»  Extension  of  positive  control  of  flight  operations  to  those  ramp 

areas  which  justify  such  control. 

©  A  systematic  logic  for  automation  of  information  exchange,  flight 

operations  management,  and  display  of  cue  information  to  tower 
personnel. 

3.2  REQUIREMENTS  ESTIMATION 

3.2.1  General 

The  RCS  conceptual  design  incorporates  the  functional  tasks  associated 
with  air  traffic  operations  within  or  related  to  the  airport  ramp  areas.    This  includes 
those  functions  now  being  performed  by  ATCT  and  airlines  operations  personnel  as 
well  as  those  additional  functions  necessary  to  more  effectively  and  efficiently 
accomplish  the  specific  performance  objectives  of  the  module. 


These  objectives  include: 

•  To  accomplish  all  information  transfer  related  to  acquisition, 
maintenance,  and  presentation  of  data  for  initiation  of  service 
to  flight  operations  within  the  airport  ramp  areas. 

•  To  accomplish  all  information  transfer  related  to  coordination 

of  flight  operations  within  the  ramp  area(s)  and  between  the  ramp 
area(s)  and  the  airport  taxiway  network. 

•  To  achieve  an  orderly  flow  of  aircraft  traffic  within  the  ramp 
area  that  affords  an  optimum  balance  between  delays  (when 
necessary)  to  outbound  and  inbound  traffic. 

The  areas  of  service  of  the  RCS  include  all  ramp  areas  associated  with 
the  airport  passenger  terminal (s),  cargo  terminal,  and  hangar  facilities.    To  ac- 
complish the  necessary  services  within  these  areas  the  module  must  achieve  opera- 
tional interfaces  between  the  ATCT  and  airline  operations,  NAS  enroute  system, 
and  ARTS  III.     The  system  (module)  must  also  achieve  operational  interfaces  with 
other  ASTC  system  modules,  i.e. ,  Ground  Control  System  (GCS)  and  Local  Control 
System  (LCS).     The  interface  with  the  Ground  Control  System  is  of  primary  impor- 
tance because  of  the  physical  interface  between  the  ramp  area(s)  and  taxiway  net- 
work and  the  requirement  to  coordinate  the  management  of  traffic  operations  at 
these  physical  interface  points. 

The  Ramp  Control  System  concepts  described  here  represent,  to  a 
significant  degree,  modification  of  current  procedures  in  airport  surface  opera- 
tions.    These  concepts  are  dependent  upon  two  underlying  or  subsidiary  concepts 
and  a  number  of  assumptions  regarding  the  manner  of  operations  in  the  ramp  areas. 
These  subsidiary  concepts  are  those  of  Positive  Ramp  Control  and  Gate  Schedules 
Data  Maintenance. 

3.  2. 1. 1        Definition  of  Positive  Ramp  Control 

An  essential  element  of  the  development  of  the  RCS  concept  is  the  sub- 
sidiary concept  of  Positive  Ramp  Control. 

In  current  operations  at  most  airports,  air  carrier  traffic  may  initiate 
their  pushback  when  it  is  determined  to  be  feasible  by  the  aircraft  crew  and  airline 


ramp  operations  and  ground  crew  personnel.  *   Where  the  physical  characteristics 
of  the  ramp  area/terminal  building  configuration  permit  free  movement  of  aircraft 
around  another  aircraft,  this  mode  of  operation  does  not  cause  any  operational  dif- 
ficulties.   However,  where  the  physical  characteristics  of  the  ramp  area/terminal 
building  configuration  does  not  permit  this  free  movement,  then  significant  opera- 
tional difficulties  may  occur.     For  departures,   this  occurs  when  a  flight  which  is 
ready  to  taxi  cannot  do  so  because  of  the  pushback  of  another  aircraft  from  a  gate 
ahead  of  the  first  aircraft's  gate.    When  this  situation  occurs,  the  delay  may  also 
result  in  the  need  for  the  ground  controller  to  resequence  the  flight  into  the  traffic 
stream.     For  arrivals,  delays  occur  when  the  flight  cannot  enter  the  ramp  area  and 
taxi  to  its  gate  because  its  way  is  blocked  by  a  departure  taxiing  out  of  the  area  or 
in  pushback  ahead  of  the  arrival's  destination  gate.    When  this  situation  occurs,  the 
ground  controller  may  have  to  hold  the  arrival  on  the  taxiway  until  the  blockage  is 
cleared,  possibly  resulting  in  delays  to  other  aircraft  following  it  or,  to  avoid 
such  delays,  issue  instructions  for  additional  taxiing  of  the  arrival. 

At  some  airports  where  this  ramp  constriction  situation  exists,  indi- 
vidual airlines  have  constructed  their  own  tower  facilities  (e.  g.  ,  United  Airlines 
and  American  Airlines  at  O'Hare)  to  afford  their  ramp  controllers  visual  surveil- 
lance of  the  ramp  areas  in  which  they  operate.  This  permits  the  ramp  controller 
to  determine  when  departure  pushback  should  be  delayed  to  avoid  interference  with 
their  other  flight  operations  or  to  avoid  conflicts  with  the  operations  of  other  air- 
lines sharing  the  same  ramp  area. 

Even  with  these  more  advanced  airline  operations,  and  certainly  where 
such  facilities  are  not  employed,  the  occurrence  of  delays  to  outbound  as  well  as 
inbound  flights  is  quite  frequent.    While  ramp  controllers  can  exercise  management 


*At  some  airports,  flights  operating  at  certain  gates  must  obtain  pushback  clearance 
from  the  tower  when  pushback  from  their  gates  would  temporarily  block  passage  of 
other  aircraft  on  the  taxiway  network  (e.g.  ,  Continental  Airlines  operations  on  gates 
D-ll  and  D-12  at  O'Hare  International  Airport). 


of  their  own  operations,  they  cannot  directly  exercise  control  of  the  operations  of 
other  airlines.    Thus,  another  airline's  flight  may  push  back  and  block  an  outbound 
or  inbound  flight.    At  O'Hare,  United  and  TWA  have  discussed  the  possibility  of 
United  providing  pushback  control  of  TWA  flights.    However,  for  several  reasons 
no  agreement  was  reached.     The  major  deterrent  was  that  the  United  tower  afforded 
visibility  of  only  the  F-G  ramp  area  which  they  share  but  not  the  G-H  area  in  which 
TWA  also  operates,  as  shown  in  Figure  3-1. 

The  objective    of  the  concept  of  Positive  Ramp  Control  is  to  achieve 
and  improve  on  the  capabilities  provided  by  the  individual  airline  ramp  control 
tower  and  to  extend  these  capabilities  to  all  ramp  areas  where  it  is  required. 
At  any  given  airport,  the  ramp  area/terminal  building  configuration  may  incorpo- 
rate areas  in  which  Positive  Ramp  Control  is  not  required  and  those  in  which  it  is. 
Those  areas  in  which  such  control  is  deemed  necessary  are  (and  will  be)  referred 
to  as  Positive  Ramp  Control  areas.    The  extent  to  which  Positive  Ramp  Control  is 
required  will  obviously  vary  from  airport  to  airport.    At   airports  such  as  O'Hare, 
LaGuardia,   Los  Angeles,  and  Atlanta,  Positive  Ramp  Control  may  be  the  predomi- 
nant mode  of  operation  with  some  areas  not  under  Positive  Ramp  Control   At 
airports  such  as  Logan,  Kennedy,  Philadelphia,  and  Newark,  Positive  Ramp 
Control  may  be  a  minor  mode  of  operation  for  only  one  or  two  areas.    At  many 
other  airports  such  as  Cleveland,  Dallas-Ft.  Worth,  San  Francisco,  and  Bal- 
timore, Positive  Ramp  Control  may  not  be  needed  at  all. 

Thus,  at  each  airport  those  ramp  areas  which  will  require  Positive 
Ramp  Control  would  have  to  be  identified.    These  would  include  all  areas  in  which: 

•  The  outbound  taxi  of  a  departure  flight  (or  aircraft  moving  from  a 
terminal  gate  to  another  airport  location)  could  be  blocked  by  push- 
back  of  another  aircraft 

•  The  inbound  taxi  of  an  arrival  flight  (or  aircraft  moving  to  a  termi- 
nal gate  from  another  airport  location)  to  its  gate  could  be  blocked 
by  pushback  of  a  departure  flight 
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Figure  3-1.    Ramp  Area/Terminal  Configuration  - 
O'Hare  International  Airport 


•       The  available  space  would  permit  simultaneous  taxi  (and  passage) 
by  two  outbound  aircraft  or  by  both  outbound  and  inbound  aircraft 
under  good  visibility  conditions  but  where  this  cannot  be  accom- 
plished with  a  sufficient  degree  of  safety  when  pilot  visibility  is 
impaired  under  poor  weather  conditions. 

The  application  of  these  criteria  to  O'Hare  for  the  passenger  terminal 
ramp  area  is  illustrated  in  Figure  3-2.     The  C-D,   D-E,   F-G,   and  G-H  ramp  areas 
are  obvious  candidates  for  Positive  Ramp  Control  areas.    The  area  to  the  east  of 
K-wing  is  a  candidate  for  Positive  Ramp  Control  because  the  presence  of  blast 
fence  limits  the  space  available  for  aircraft  movement.    Moreover,  based  upon  the 
airport  management's  indicated  anticipation  of  construction  of  an  L-wing  in  the 
future,  this  area  would  probably  remain  a  candidate  for  Positive  Ramp  Control. 
The  area  to  the  north  of  the  B-wing  is  not  currently  estimated  to  require  Positive 
Ramp  Control  even  with  the  presence  of  general  aviation  traffic  at  the  Butler  ramp. 
However,  with  the  airport  management's  anticipated  future  construction  of  an 
A -wing  (and  a  new  general  aviation  terminal),  Positive  Ramp  Control  for  this  area 
may  become  necessary. 

Therefore,  the  concept  of  the  Ramp  Control  System  provides  for  in- 
corporation of  Positive  Ramp  Control  and  non-Positive  Ramp  Control  modes  of 
operation  for  departure  and  arrival  aircraft  as  a  function  of  the  origination/desti- 
nation gate  of  the  aircraft.    Positive  Ramp  Control  in  designated  areas  would  be 
applied  to  both  normal  aircraft  departure/arrival  flights  as  well  as  to  flights  mov- 
ing between  these  areas  and  terminal  facilities  (i.e. ,  cargo  and  hangar  areas). 
Depending  on  the  configuration  of  the  airport  cargo  and  hangar  areas,  these  areas 
could  also  come  under  Positive  Ramp  Control. 

As  noted  earlier,  the  concept  of  Positive  Ramp  Control  is  to  improve 
on  and  extend  the  capabilities  now  achieved  by  the  individual  airline  control  tower. 
A  number  of  approaches  were  considered  in  developing  the  Ramp  Control  System 
concepts  described  in  this  section.    These  included: 
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1.  Provision  of  Positive  Ramp  Control  through  the  airlines  with  each 
airline  provided  with  sufficient  capability  to  control  its  own  flights 
in  relation  to  other  flights  operating  in  the  same  ramp  area. 

2.  Provision  of  Positive  Ramp  Control  through  the  airlines  but  where 
these  responsibilities  would  be  exercised  by  one  or  more  airlines 
serving  their  own  and  other  airlines'  flights. 

3.  Provision  of  Positive  Ramp  Control  by  FA  A  personnel  operating 
in  suitable  locations,   such  as  existing  airline  towers. 

4.  Provision  of  centralized  Positive  Ramp  Control  by  FAA  personnel 
operating  in  a  single  location,  i.e.,  the  ATCT. 

Each  of  these  approaches  has  certain  merits  and  disadvantages.    At 
O'Hare,  for  example,  the  American  and  United  towers  could  be  readily  used  to 
provide  control  in  the  D-E,   E-F,   F-G,  G-H,   H-K,   and  K  positive  ramp  areas 
within  approaches  2  and  3  above.    However,  these  locations  are  not  adequate  for 
control  of  the  B-C  and  C-E  Positive  Ramp  Control  areas.    It  is  recognized  that  an 
additional  facility  could  be  constructed  to  serve  these  areas  or,  in  the  case  of  3_ 
above,  this  could  be  accomplished  from  the  ATCT. 

After  due  consideration,  approach  4  above  was  adopted  as  a  preliminary 
approach.     The  primary  factors  in  this  determination  included  the  following: 

1.  It  is  applicable  to  all  airport  configurations  independent  of  the 
availability  of  airline  control  towers  or  other  suitable  locations. 

2.  Agreements  between  airlines  over  control  of  each  other's  operation 
may  be  potentially  difficult  to  achieve. 

3.  Centralization  of  all  required  information,  information  processing, 
and  display  of  conflicts  at  a  single  location  for  decision  making 
appears  more  practical,  both  operationally  and  technically. 

4.  Vesting  of  control  authority  in  a  non-airline  position  would  avoid 
potential  disagreements  over  favoritism  and  provide  more  objec- 
tive ramp  area  management. 


Thus,  it  has  been  assumed  the  Positive  Ramp  Control  as  well  as  other 
functional  responsibilities  of  the  Ramp  Control  System  would  be  exercised  by  the 
ATCT  through  Ramp  Control  positions.     The  extent  to  which  these  responsibilities 
could  be  exercised  through  expansion  of  the  role  of  the  existing  Clearance  Delivery 
position  or  would  require  an  additional  position  in  the  ATCT  would  be  determined 
by  the  volume  of  traffic  and  the  degree  of  Positive  Ramp  Control  required  in  pro- 
portion to  other  Ramp  Control  System  operations.    In  either  case  the  exercise 
of  these  functions  will  require  data  exchange  with  the  airlines  as  discussed  in  the 
following  section. 

3.  2. 1.  2         Gate  Schedules  Data  Maintenance 

The  second  subsidiary  concept  within  the  development  of  the  Ramp  Con- 
trol System  concept  is  the  maintenance  and  application  of  gate  schedules  data.     This 
concept  is  important  for  several  reasons.     First,  knowledge  of  the  ramp  location 
(gate)  from  which  a  flight  is  departing  or  for  which  a  flight  is  arriving  will  deter- 
mine whether  it  will  come  under  Positive  Ramp  Control.    Second,  knowledge  of  the 
ramp  location  of  a  departure  is  necessary  for  the  ASTC  system  functions  of  routing 
to  the  runway,   sequencing  the  flight  in  the  taxi  flow  pattern,  and  determination  of 
conflicts  with  arrival  aircraft  for  the  same  ramp.     Third,  knowledge  of  the  desti- 
nation gate  for  arrivals  and  the  availability  of  the  gate  is  necessary  for  routing  of 
the  flight  by  ground  control  operations. 

Currently,  origination  gate,  destination  gate,  and  availability  are  de- 
termined by  direct  communications  between  the  ATCT  and  the  flight.    The  objec- 
tive of  this  subsidiary  concept  is  to  obtain  and  maintain  this  data  in  a  more  timely 
and  efficient  manner  in  order  to  reduce  controller  and  pilot  communications  work- 
load and  more  effectively  manage  system  operations. 

Discussions  with  airlines  personnel  during  the  preceding  O'Hare  Opera- 
tions Analysis  indicated  that  preplanned  gate  schedules  are  developed  whenever 
major  rescheduling  of  flight  operations  occurs.     Temporary  adjustments  to  these 


schedules  are  made  when  special  flights  are  added  to  their  schedule  or  when  gate 
changes  are  necessitated  by  the  operational  situation  (delays,  equipment  changes, 
etc . ) . 

The  concept  incorporated  here  is  based  upon  storage  of  the  preplanned 
gate  schedules  in  the  Airport  Surface  Traffic  Control  (ASTC)  system  data  base  for 
reference  by  the  Ramp  Control  System.     This  data  base  would  be  updated  when 
temporary  adjustments  are  made  through  direct  communications  with  the  airlines' 
flight  operations.    To  maximize  the  efficiency  of  these  communications  it  is  antici- 
pated that  digital  data  transfer  between  flight  operations  and  the  ASTC  system  would 
be  accomplished  through  suitable  terminal  devices  (Automated  Gate  Status  Equip- 
ment) in  the  airline  flight  operations  facilities. 

The  concept  further  provides  that  this  gate  schedule  data  base  be 
maintained  on  a  dynamic  basis  by  the  internal  processing  of  the  Ramp  Control 
System.    The  purpose  of  this  is  to  maintain  a  reference  of  the  current  status  of 
occupancy  of  gates  (e.  g. ,  open,  occupied,  aircraft  off  gate  but  not  yet  departed). 
This  information  would  be  employed  by  the  Ground  Control  System  in  determining 
whether  an  arrival  can  be  routed  directly  to  its  gate  or  must  be  routed  to  an  interim 
holding  area  (e.g. ,  O'Hare's  Penalty  Box). 

One  of  the  basic  requirements  of  this  subsidiary  concept  as  well  as 
that  of  Positive  Ramp  Control  is  a  positive  data  entry  that  the  aircraft  has  docked 
or  parked  at  its  gate. 

It  is  fully  recognized  that  this    concept,  involving  direct  operational 
interface  between  proposed  RCS  and  airline  flight  operations,  is  new  to  airport 
operations  and  that  its  implementation  will  require  acceptance  by  the  airlines. 
However,  substantial  benefits  to  both  airline,  ATC,   and  airport  operations  should 
result. 


3.2.1.3         Basic  Assumptions 

The  RCS  concepts  described  here  were  developed  to  be  generally  appli- 
cable to  a  broad  range  of  environments  at  major  airports.  The  concepts  provide 
for  airport  configurations  including  both  positive  and  non-positive  ramp  areas  as 
well  as  a  mix  of  IFR  and  VFR  traffic.  To  satisfy  this  objective,  several  assump- 
tions were  made  relative  to  the  nature  of  the  ramp  control  services  provided  and 
to  traffic  procedures  within  the  ramp  areas.    These  assumptions  are: 

•  Control  of  flight  movements  from/to/within  the  ramp  area  will 
be  accomplished  primarily  as  a  scheduling  function 

•  No  real-time  sensor  surveillance  for  control  of  aircraft  lineal 
(forward)  and  lateral  (turning)  movements  will  be  performed 

•  No  real-time  guidance  of  aircraft  lateral  (turning)  maneuvers 
will  be  provided 

•  Departure  flights  or  flights  to  cargo/hangar  areas  will  remain 
in  pushback  position  until  receipt  of  positive  clearance  to  taxi 
from  Ground  Control;  i.e.,  they  will  not  move  toward  the  outer 
edge  of  ramp  area  while  waiting  for  such  clearance 

•  Where  sufficient  ramp  surface  exists  for  an  aircraft  to  hold  (off 
the  taxiway  network)  while  waiting  for  the  ramp  to  clear  for  taxi 
to  its  gate,  Ground  Control  may  clear  a  flight  off  the  taxiways  to 
the  ramp  area  with  instructions  to  "monitor  Ramp  Control".  The 
flight  would  remain  in  the  holding  position  until  cleared  by  Ramp 
Control  for  taxi  to  its  gate. 

3.2.2  Functional  Requirements 

The  major  functions  to  be  performed  by  the  Ramp  Control  System  have 
been  derived  from  the  detailed  study  of  existing  ASTC  system  procedures  and  flight 
operations  during  the  period  of  service  within  the  ramp  areas.  These  functions  are 
for  the  most  part  defined  for  implementation  employing  semi-automated  control 
techniques  to  improve  system  effectiveness  and  efficiency.  No  provision  for  auto- 
mated transmission  of  data  to  aircraft  flight  deck  has  been  considered.  Therefore, 
transmission  of  clearances,  control  instructions  to  aircraft,  and  pilot  reports  of 


flight  status  are  by  voice  radio.     Further  improvements  in  the  concepts    outlined 
herein  could  be  achieved  in  the  future  with  the  introduction  of  data  links  or  by 
DABS. 

3.2.2.1        Identification  of  Control  Functions 

The  RCS  functions  may  be  divided  into  three  categories,  based  upon 
whether  they  are  required  for  departures  (outbound)  or  arrival  (inbound)  flights 
or  are  common  to  both.    These  functions  include: 

Departures 

A.  Flight  Clearance  Delivery 

B .  Maintain  Outbound  Ramp  Q 

C.  Pushback  Clearance 

D.  Inter-Departure  Conflict  Management 

E.  Handoff  to  Ground  Control  Departure  Q 

Arrivals 


F.  Verify  Gate  Assignment 

G.  Monitor  Inbound  Ramp  Q 
H.     Clear  to  Gate 

Common 


J.      Outbound/Inbound  Conflict  Management 

Each  of  these  functions  is  examined  in  order  to  determine  the  informa- 
tion needed  for  data  processing  and  decision  making  by  the  system  computer  equip- 
ment, controller,  or  airlines  operations  to  perform  the  appropriate  job  (or  task). 
There  is  a  substantial  amount  of  interaction  between  many  of  these  functions.     For 
example,  Function  C  requires  that:  (1)  Function  A  has  been  accomplished;  (2) 
Function  D  (no  conflict  with  other  departures  in  the  same  ramp  area)  is  satisfied; 
and  (3)  Function  J  (no  conflict  with  inbound  flights  to  the  same  ramp  area)  is  satis- 
fied.   However,   Function  J  also  requires  that  Function  G  has  been  accomplished. 


As  another  example,  in  current  operating  procedures  the  equivalent  of 
Function  E  is  accomplished  as  soon  as  a  flight  indicates  it  is  ready  to  taxi.  * 
Ground  Control  may  contact  the  flight  immediately  for  taxi  or  may  delay  contact 
because  of  other  operational  demands  (e.g. ,  another  departure  in  the  same  ramp 
area  which  must  taxi  out  first).     Even  after  contact  is  established,  compliance 
with  Ground  Control  instructions  could  be  blocked  by  the  actions  of  another  out- 
bound or  inbound  flight.     For  the  proposed  RCS  concept,   Function  E  would  be 
accomplished  only  when  potential  conflicts  with  the  movement  of  the  aircraft  have 
been  determined  not  to  exist  or  have  been  resolved  and,  therefore,  that  the  flight 
may  move  without  delay  when  contacted  by  Ground  Control.    In  effect,  then,  this 
function  reserves  the  ramp  area  between  the  region  of  the  departure's  gate  and 
the  ramp/  taxi  way  interface  point  for  its  exclusive  movement. 

Table  3-1  lists  the  major  functions  required  in  the  Ramp  Control  Sys- 
tem (module).    The  second  column  identifies  where  interface  is  required  with  the 
Ground  Control  and  Local  Control  Systems,  with  airline  flight  operations,  and  with 
the  NAS  enroute  and  ARTS  III  systems.     The  third  column  lists  (in order)  the  sequence 
of  events  or  interacting  functions  which  must  be  recognized  or  performed  in  accom- 
plishing the  function.    In  the  case  of  Function  D,  Inter-Departure  Conflict  Manage- 
ment, the  table  shows  an  interaction  with  Functions  B  and  C  at  the  start  of  the  se- 
quence.   These  are  essentially  requests  for  the  performance  of  Function  D.    How- 
ever, if  an  inter-departure  conflict  is  determined  to  exist,  the  sequence  will  return 
to  the  initiating  functions.    The  return  is  not  specifically  indicated  to  avoid  redun- 
dant listing  of  the  interacting  function.    The  same  is  true  for  Function  J,  Outbound- 
Inbound  Conflict  Management,  in  relation  to  Functions  D  and  G.    Where  applicable 
the  entries  in  this  column  have  been  classified  as  "Demand",   "Start  of  Service", 
or  "End  of  Service".    These  terms  are  intended  to  identify  the  entry  of  a  demand 


*Assuming  that  gate  hold  procedures  have  not  been  put  into  effect  because  of  ex- 
tensive operational  delays. 
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for  performance  of  the  function,  start  of  service  to  an  individual  flight,  or  end  of 
service  to  an  individual  flight. 

In  general,  "Demand"  events  involve  the  receipt  of  a  request  for  per- 
formance of  the  function  by  an  interacting  function  or  from  an  external  interface 
(e.g. ,  NAS  enroute  system).    The  exceptions  are  the  pilot's  indication  that  the 
flight  is  ready  to  taxi  for  Function  B,  Monitor  Outbound  Ramp  Q,  and  the  pilot's 
request  for  pushback  clearance  for  Function  C,  Pushback  Clearance.    In  general, 
the  flight  will  have  already  received  service  from  the  RCS  under  Function  A, 
Flight  Clearance  Delivery.     "Start  of  Service"  events  involve  the  initial  radio  con- 
tact with  the  flight  awaiting  service  by  the  RCS.    "End  of  Service"  events  are,  as 
indicated,  an  end  of  service  to  the  flight  by  the  RCS  and  involve  communications 
with  the  flight  (or  possibly  airline  operations  when  the  flight  docks  or  parks  at  its 
gate).    Typically,  "Start  of  Service"  and  "End  of  Service"  events  require  a  real- 
time data  entry  by  ACTC  or  airline  operations  personnel.    The  "Demand"  events 
for  Functions  B  and  C  will  also  require  real-time  data  entry  by  ATCT  or  airline 
operations  personnel. 

The  fourth  column  in  Table  3-1  indicates  the  data  required  for  the  per- 
formance of  the  function  by  the  data  processing  equipments.    These  data  require- 
ments may  be  derived  from  ASTC  system  data  bases  or  ATCT/airline  operations 
personnel. 

The  fifth  column  indicates  specific  real-time  data  entries  that  must  be 
accomplished  by  the  ATCT  or  airline  operations  personnel  to  initiate  the  perform- 
ance or  within  the  performance  sequence  of  the  function. 

The  last  column  provides  particular  qualifying  remarks  pertaining  to 
the  performance  of  the  functions  or  events  with  the  performance  sequence. 

3.  2.  2.  2        Organizational  Interaction  of  Functions 

The  interaction  of  the  Ramp  Control  System  functions  can  be  readily 
viewed  as  the  logical  and  sequential  processing  of  information  within  the  ASTC 
system  data  base  organization.     This  is  illustrated  in  Figure  3-3. 


Flight  clearances  for  IFR  departures  are  received  from  the  ARTCC. 
They  are  delivered  to  the  pilots  when  they  call  for  their  clearances.    As  indicated, 
in  the  event  that  a  change  in  the  flight  clearance  is  requested,  it  will  be  coordinated 
with  the  ARTCC .    The  data  contained  in  the  final  clearance  as  well  as  the  preplanned 
gate  schedules  may  then  be  combined  and  stored  in  a  Departure  Flights  Data  file 
for  ready  reference  when  the  flight  is  ready  for  departure. 

Flight  clearances  for  VFR  flights  will  also  be  delivered  when  the  pilot 
calls  for  entry  into  the  system.    In  this  instance,  the  beacon  codes  to  be  employed 
by  the  flights  will  be  assigned  from  a  list  of  available  codes  obtained  through  the 
interface  with  ARTS.     Flight  clearance  data  and  the  assigned  beacon  codes  may  then 
be  combined  in  the  Departure  Flights  Data  file.    Since  the  flights  are  ready  to  taxi 
upon  receipt  of  their  clearance,  they  may  be  immediately  entered  into  Ground  Con- 
trol Departure  Q  for  service  by  the  Ground  Control  System.    The  Ground  Control 
Departure  Q  represents  the  list  of  aircraft  waiting  for  service  by  the  Ground  Con- 
trol System,  i.e.,  waiting  for  instructions  to  enter  the  taxiway  network  from  the 
ramp  areas. 

As  general  aviation  flights  with  IFR  clearances  are  also  ready  to  taxi 
when  they  receive  their  clearance,  they  are  also  immediately  entered  into  the 
Ground  Control  Departure  Q. 

After  some  time,  air  carrier  flights  are  ready  for  pushback.     Flights 
from  non-Positive  Ramp  Control  areas  will  push  back  and  contact  Ramp  Control  when 
ready  to  taxi.    They  may  then  be  entered  into  the  Ground  Control  Departure  Q. 
Flights  in  Positive  Ramp  Control  areas  will  call  for  their  pushback  clearance. 
They  would  be  entered  into  the  Outbound  Ramp  Q  for  service.    The  Outbound  Ramp 
Q  represents  the  list  of  aircraft  in  Positive  Ramp  Control  areas  awaiting  or  re- 
ceiving service  by  the  RCS  in  controlling  their  transition  from  pushback  to  the 
Ground  Control  Departure  Q.    Ramp  conflict  management  processing  would  deter- 
mine the  status  of  other  flights,  if  any,  in  the  Ground  Control  Departure  Q  and  Out- 
bound Ramp  Q  for  the  particular  ramp  areas.    If  there  is  a  conflict,  the  flights 


would  be  advised  to  hold  at  their  gate  and  the  process  repeated  in  the  next  process- 
ing cycle.    If  there  is  no  conflict  with  other  outbound  flights,  the  ramp  conflict 
management  processing  would  then  determine  the  existence  of  any  flights  for  the 
particular  ramp  areas  in  the  Inbound  Ramp  Q  established  by  the  Ground  Control 
System.     The  Inbound  Ramp  Q  represents  the  list  of  aircraft,  both  still  in  the  taxi- 
way  network  approaching  the  turnoffs  to  the  gates  and  holding  in  ramp  areas,   re- 
quiring service  by  the  RCS  in  providing  clearance  to  their  gates.    In  the  event  of  a 
conflict  the  flights  would  be  advised  to  hold  at  their  gates  and  the  process  repeated 
in  the  next  cycle.    If  no  conflicts  are  determined,  then  the  flights  are  cleared  for 
pushback  and  their  status  in  the  Outbound  Ramp  Q  updated. 

A  short  time  later  the  flights'  pilots  will  call  for  taxi.    Their  status 
will  then  be  updated  in  the  Outbound  Ramp  Q.     The  ramp  conflict  management 
processing  will  then  be  accomplished  as  previously  described.    If  there  is  no  con- 
flict, the  flight  may  then  be  entered  into  the  Ground  Control  Departure  Q. 

Simultaneously  with  the  updating  of  the  flights'  status  data  in  the  Out- 
bound Ramp  Q,  the  Gate  Schedules  data  will  be  updated.  The  updating  will  reflect 
the  availability  of  the  gates  for  arrivals  entering  the  system.  This  data  may  also 
be  updated  by  airlines  flight  operations  personnel  when  adjustments  to  the  normal 
flight  Gate  Schedules  are  anticipated. 

This  data  will  be  accessed  in  relation  to  flights  entered  into  the  Ground 
Control  Arrivals  Q  list  by  the  Local  Control  System.    When  necessary,  the  gate 
availability  verification  process  will  require  interaction  with  airlines  flight  opera- 
tions to  determine  a  revised  gate  assignment  and/or  delay  in  the  availability  of  the 
assigned  gate  for  the  flight. 

At  a  later  time  the  flights  approaching  the  appropriate  point  of  exit  from 
the  taxiway  network  for  their  assigned  gates  will  be  entered  into  the  Inbound  Ramp 
Q  by  the  Ground  Control  System.     Flights  assigned  to  gates  in  non-Postiive  Ramp 
Control  areas  will  be  cleared  to  their  gates  by  Ground  Control.     For  flights  inbound 
to  Positive  Ramp  Control  areas,  the  ramp  conflict  management  processing  will 


determine  whether  the  Ground  Control  Departure  Q  or  Outbound  Ramp  Q  contains 
conflicting  departures  for  the  appropriate  ramp  areas.    When  there  are  no  con- 
flicts, the  flights  will  be  cleared  to  the  gates  by  Ground  Control  System  and  their 
status  in  the  Inbound  Ramp  Q  updated.    When  there  are  conflicts,  Ground  Control 
will  retain  control  of  the  flights  or,  when  possible,  may  clear  flights  off  the  taxi- 
way  network  into  a  portion  of  the  ramp  area  out  of  the  way  of  the  Positive  Ramp 
Control  area  traffic  until  it  is  cleared  to  the  gate  by  Ramp  Control.    In  the  latter 
event,  the  status  of  the  flights  in  the  Inbound  Ramp  Q  would  be  updated.    When 
ramp  conflict  management  processing  subsequently  determines  that  a  conflict  situ- 
ation no  longer  exists,  such  holding  flights  will  be  cleared  to  their  gates  and  their 
status  in  the  Inbound  Ramp  Q  updated. 

When  the  flights  have  docked  or  parked  at  their  gates,  they  will  be  de- 
leted from  the  Inbound  Ramp  Q.    Simultaneously,  the  Gate  Schedules  data  will  be 
updated  to  reflect  that  the  gate  is  now  occupied. 

3.2.3  Description  of  Information  Transfer  for  Individual  Functions 

The  logical  processing  requirements  for  the  performance  of  each  Ramp 
Control  System  function  has  been  developed  in  detail.     Flow  diagrams  and  brief 
narrative  descriptions  of  each  function  are  given  below. 

3.2.3.1         Flight  Clearance  Delivery  (Function  A) 

The  functional  flow  for  Flight  Clearance  Delivery  is  illustrated  in 
Figure  3-4. 

For  IFR  flights  the  process  begins  with  the  receipt  of  flight  clearances 
and  any  applicable  delay  restrictions  from  the  ARTCC.  Currently  the  flight  clear- 
ances are  received  and  strips  printed  out  at  the  FDEP  in  the  tower.  However,  the 
Operations  Analysis  at  O'Hare  indicated  that  a  significant  degree  of  marking  of  the 
strips  is  then  required  by  ATCT  personnel.    This  includes: 

•       Annotating  the  equipment  type  for  heavy  aircraft  and  the 
first  fix 
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Figure  3-4.    Flight  Clearance  Delivery  -  Functional  Flow  Diagran 


•  Correcting  the  cleared  altitude  to  the  clearance  limit  that 
can  be  issued  for  the  tower/TRACON 

•  Entering  the  origination  gate 

t       Entering  the  runway  to  which  the  flight  is  cleared  for  departure 

In  addition,   Flight  Clearance  Delivery  must  manually  prepare  a  flight 
strip  for  VFR  departures. 

It  has  been  assumed  that  the  use  of  flight  strips  will  be  retained  to  pro- 
vide a  means  of  manual  backup  in  the  event  of  system  equipment  failures.  There- 
fore, the  proposed  concept  for  this  function  provides  for  a  revised  method  of  flight 
strip  preparation  which  minimizes  the  need  for  the  strip  marking  listed  above. 

The  data  contained  in  the  flight  clearances  and  delay  restrictions  pro- 
vided by  the  ARTCC  would  be  combined  with  the  Gate  Schedule  data  and  the  standard 
criteria  for  runway  assignment  to  generate  a  composite  flight  clearance.    The  flight 
strip  would  then  be  printed  with  the  appropriate  altitude  clearance  limit  (if  applicable), 
flight  originating  gate,   and  nominally  assigned  runway.    It  is  further  assumed  that 
improvements  could  be  made  to  the  flight  strip  printer  to  provide  for  special  annota- 
tion of  the  flight  equipment  type  for  heavies  and  the  first  fix. 

For  VFR  flights  the  ATCT  personnel  would  enter  the  necessary  data 
for  the  flight.    This  would  include  the  flight  call  sign  (ID),  equipment  type,  beacon 
equipment  type,  and  desired  altitude  and  direction  of  flight  out  of  terminal  area. 
This  data  would  be  combined  with  a  beacon  code  selected  from  a  list  of  available 
codes  provided   by  ARTS  to  prepare  a  flight  strip. 

For  IFR  flights  the  tower  personnel  would  enter  an  acceptance  of  the 
clearance  delivered.    This  effectively  enters  the  flights  into  the  system  for  further 
service.     For  air  carrier  flights  this  would  involve  establishment  of  the  flight  in  the 
Departure  Flights  Data  file  until  it  is  ready  for  further  service  by  the  ASTC  system. 
This  file  is  intended  to  contain  only  that  reference  data  necessary  for  further  service 
by  the  ASTC  system.    This  data  could  possibly  be  displayed  to  ground  controllers  for 
planning  purposes.    It  is  estimated  that  this  data  would  include: 


Call  sign 

Equipment  type  or  class 

Beacon  code 

Computer  number,  if  applicable 

Originating  gate 

Departure  fix  (  or  direction  of  flight  for  VFRs) 

Nominal  runway  assignment 

Delay  restrictions,  if  applicable 

For  VFRs  and  general  aviation  IFRs,  upon  delivery  of  the  clearance  the 
pilot  would  be  directed  to  "taxi  up  to  the  taxiway  and  activate  your  beacon  when  ready- 
to-taxi".    The  ASTC  system  sensor  (e.g. ,  GEOSCAN)  would  automatically  detect  the 
beacon  and  transfer  the  aircraft  to  the  Handoff  to  Ground  Control  Departure  Q  func- 
tion for  further  processing. 

3.  2.  3.  2        Maintain  Outbound  Ramp  Q  (Function  B) 

The  functional  flow  for  the  Maintain  Outbound  Ramp  Q  is  illustrated  in 
Figure  3-5.    This  function  applies  only  to  air  carrier  flights.    These  flights  will 
enter  the  function  for  service  from  the  other  two  functions  depending  upon  whether 
they  are  originating  from  gates  in  Positive  or  non-Positive  Ramp  Control  areas. 

When  the  pilot  indicates  that  the  flight  is  ready  for  taxi,  the  ATCT  per- 
sonnel will  enter  this  into  the  system.     Flights  in  non-Positive  Ramp  Control  areas 
will  be  transferred  to  the  Handoff  to  Ground  Control  Departure  Q  function.     The 
data  for  the  flight  will  be  transferred  from  the  Departure  Flights  Data  file. 

For  a  flight  in  Positive  Ramp  Control  areas,  its  status  would  be  up- 
dated in  the  Outbound  Ramp  Q.     The  ramp  conflict  management  functions  would 
then  be  called  for  processing  of  the  flight's  request  for  taxi.    If  no  conflicts  are 
determined,  the  flight  would  be  transferred  to  the  Handoff  to  Ground  Control  De- 
parture Q  function.        If  a  conflict  is  determined,  the  flight  would  be  instructed  to 
hold  in  position.     The  flight  would  be  re-entered  for  the  ramp  conflict  management 
functions  in  the  next  cycle. 
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Figure  3-5.    Maintain  Outbound  Ramp  Queue  -  Functional  Flow  Diagram 


3.2.3.3         Pushback  Clearance  (Function  C) 

The  functional  flow  for  Pushback  Clearance  is  illustrated  in  Figure  3-6. 
This  function  serves  only  flights  originating  in  Positive  Ramp  Control  areas. 

When  the  pilot  requests  Pushback  Clearance  the  request  would  be 
entered  into  the  system.    There  are  two  possible  methods  by  which  this  process 
may  occur.    The  pilot  could  directly  contact  the  appropriate  ATCT  personnel 
(Ramp  Control)  requesting  pushback  and  the  entry  made  by  the  ATCT  personnel 
(Ramp  Control).     As  it  is  currently  normal  procedure  for  pilots  to  request  an 
authorization  to  pushback  from  their  own  flight  operations  personnel,   the  request 
entry  could  be  made  by  these  personnel.     The  latter  approach  would  be  desirable 
from  the  point  of  view  of  minimizing  ATCT  (Ramp  Control)  personnel  voice  chan- 
nel and  data  entry  workload.    However,  it  would  require  agreement  by  the  airlines. 

A  third  alternative  is  also  possible  but  would  require  installation  of 
data  link/data  entry  equipment  aboard  aircraft.    This  approach  might  be  considered 
for  future  system  evolution. 

The  flight's  status  in  the  Outbound  Ramp  Q  would  be  updated.    The  ramp 
conflict  management  functions  would  then  be  called  for  processing  of  the  flight's  re- 
quest.   If  a  conflict  is  determined  the  pilot  would  be  instructed  to  hold  at  the  gate 
and  the  flight  scheduled  for  further  ramp  conflict  management  processing  in  the 
next  cycle.    If  no  conflict  is  determined  the  flight  would  be  cleared  for  pushback. 
The  ATCT  (Ramp  Control)  personnel  or  airline  flight  operations  would  enter  the 
pushback  into  the  system  updating  the  Outbound  Ramp  Q  and  Gate  Schedules. 

3.  2.  3.4        Inter-Departure  Conflict  Management  (Function  D) 

The  functional  flow  for  the  Inter-Departure  Conflict  Management  is  il- 
lustrated in  Figure  3-7.  This  function  applies  only  to  outbound  flights  in  Positive 
Ramp  Control  areas. 

Flights  will  enter  this  function  from  either  the  Pushback  Clearance  or 
Maintain  Outbound  Ramp  Q  functions,  depending  upon  their  pre-taxi  status. 
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Figure  3-7.     Interdeparture  Conflict  Management  -  Functional  Flow  Diagram 


The  logical  flow  of  the  process  can  be  readily  followed  from  Fig- 
ure 3-7  once  some  of  the  basic  concepts  of  the  logic  are  understood.    Therefore, 
it  will  not  be  followed  in  detail  here.    Rather,  these  basic  concepts  are  defined. 

The  inherent  rationale  of  this  conflict  management  logic  is  that  flights 
in  a  "higher"  status  of  readiness  to  taxi  are  given  priority  over  flights  in  "lower" 
readiness  status.    Proposed  statuses  would  include: 

•  In  (handed  off  to)  Ground  Control  Departure  O 

•  Ready  to  Taxi  (in  pushback  position) 

•  In  Pushback  (but  not  ready  to  taxi) 

•  Pushback  Request 

In  addition,  priority  is  dependent  upon  the  relative  locations  (i.  e.  , 
originating  gates)  of  subject  flights  (i.  e.  ,  flights  requesting  advancement  to  next 
higher  status)  and  competing  flights  in  the  same  ramp  control  area.    In  this  con- 
text, a  flight  is  termed  to  be  ahead  of  another  flight  if  its  originating  gate  is 
literally  farther  out  in  the  ramp  area  toward  the  taxiway  network  than  the  other 
flights.    It  is  not  ahead  of  another  flight  if  their  gates  are  effectively  abreast  of 
each  other  in  the  ramp  area,  i.  e.  ,  the  pushback  of  one  flight  would  block  the  push- 
back  of  the  other. 

Therefore,  when  a  subject  (requesting)  flight  is  not  ahead  of  a  com- 
peting flight  in  the  same  ramp  area,  it  would  be  allowed  to  advance  to  the  next 
higher  status  where  there  would  be  no   conflict  with  the  readiness  status  priority 
rationale.    This  would  also  be  true  if  the  subject  field  is  ahead  of  a  competing 
flight  of  a  lower  readiness  status  than  the  one  requested.    However,  a  subject 
flight  would  not  be  allowed  to  advance  to  the  next  readiness  status  if  in  doing  so  it 
would  impede  (delay)  the  movement  of  a  competing  flight  in  a  higher  status.    The 
determination  of  whether  its  advancement  would  impede  the  competing  flight  is 
then  made  in  terms  of  the  status  of  the  competing  flight  and,  in  some  instances, 
the  length  of  time  competing  flight  has  been  in  that  status.    This  is  further  dis- 
cussed below  for  each  instance. 


The  first  checks  in  the  process  are  made  to  determine  whether  there 
are  any  competing  flights  in  the  Ground  Control  Departure  Q  for  the  ramp  since 
they  are  in  the  highest  priority.    Where  a  subject  flight  is  ahead  of  a  competing 
flight  in  this  status,  it  will  normally  be  held  in  its  current  status.    There  may  be 
one  exception  when  the  subject  flight  is  ready  to  taxi  and  the  competing  flight  has 
not  been  in  the  Ground  Control  Departure  Q  for  a  period  of  time  equal  to  greater 
than  TH,  where  T     is  a  parameter  of  the  system.    The  rationale  for  this  concept 
is  that  if  T-j  is  established  at  a  sufficiently  low  value,  then  it  would  be  improbable 
that  ground  control  had  acted  to  clear  the  flight  to  taxi  and  enter  the  Ground  Control 
system.    Therefore,  the  subject  flight  could  also  be  entered  into  the  Ground  Con- 
trol Departure  Q  without  significantly  impeding  the  movement  of  the  competing 
flight.    A  value  of  T     =  30  seconds  may  be  reasonable. 

Similar  approaches  are  proposed  for  the  following  situations: 

•  Subject  flight  is  in  ready-to-taxi  status  and  the  competing 
flight  is  also  in  ready-to-taxi  status  but  has  been  in  this 
status  for  less  than  a  time  T    . 

•  Subject  flight  is  in  pushback  request  status  and  the  com- 
peting flight  is  in  pushback  status  but  has  been  in  this 
status  for  less  than  a  time  T   . 

P 

Estimates  of  possible  value  for  T     and  T    may  be  determined  on  the 
basis  of  the  observations  of  flight  operations  in  the  ramp  areas  during  the  O'Hare 
Operations  Analysis.  The  observations  indicated  pushback  times  (i.  e.  ,  from  initia- 
tion of  pushback  to  uncoupling  of  the  tug  tow  bar)  ranging  from  10  seconds  to  170 
seconds,  with  an  average  of  73  seconds.    The  observations  also  indicated  engine 
start  times  (i.  e.  ,  from  uncoupling  to  initiation  of  taxi  ranging  from  10  seconds  to 
175  seconds  with  an  average  64  seconds.    If  T    and  T     were  set  at  appropriate 
fractions  of  the  pushback  time  and  engine  start  times,  respectively,  then  only  a 
portion  of  the  competing  flights  might  be  slightly  delayed  in  their  total  service 
time  in  the  ramp  area.    If  these  fractions  were  set  at  one-half,  then  fifty  percent 
of  flights  determined  to  be  competing  flights  might  be  delayed  one-half  of  the 
pushback  or  taxi  delay  times,  i.  e.  ,  36.5  seconds  or  32  seconds,  respectively. 


The  incorporation  of  the  above  parametric  decision  approaches  is 
based  upon  the  following  rationale.    The  most  efficient  utilization  of  the  ramp  area, 
system  processing  capacity,  and  controller  flight  handling  capability  will  be  ac- 
complished when  the  ramp  area  is  serving  more  than  one  departure  at  a  time. 
Thus,  it  will  be  of  advantage  to  allow  as  many  flights  as  is  practical  to  be  active 
in  the  ramp  area  in  various  stages  of  readiness.    To  accomplish  this  some  tol- 
erances can  be  applied  in  possibly  introducing  a  small  amount  of  delay  to  a  limited 
portion  of  all  departures.    The  appropriate  balance  between  system  efficiency,  de- 
gree of  delays,  and  the  portion  of  flights  can  be  achieved  by  judiciously  selecting 
the  parameter  values  for  T„,  T   ,  and  T    . 

However,  it  has  been  recognized  that  there  is  a  practical  upper  limit 
to  the  number  of  departures  that  can  be  active  in  a  ramp  area  in  various  stages  of 
readiness.  If  too  many  departure  flights  are  active  in  the  ramp  area,  this  could 
lead  to  an  increased  probability  of  the  ramp  being  unavailable  for  use  by  arrivals 
with  destination  gates  in  the  ramp.  This  in  turn  could  result  in  increased  proba- 
bility of  delays  to  flights  or  added  workload  on  the  Ground  Control  System. 

A  possible  illustration  of  this  situation  is  shown  in  Figure  3-8,  ex- 
tracted from  an  aerial  photograph  of  O'Hare  Airport.    The  figure    shows  four 
departures  active  in  the  F-G  ramp  area.    The  status  of  the  B-747  at  gate  F-3A  is 
not  known  with  any  certainty  but,  since  the  jetway  is  not  connected,  it  could  be 
preparing  for  pushback  as  well.    The  figure  also  indicates  two  arrivals  taxiing 
on  the  Inner  Circular  taxiway.    If  either  of  these  flights  have  a  destination  gate 
in  this  ramp  there  could  be  significant  delay  in  the  availability  of  the  ramp  for  taxi 
to  its  gate.    If  the  affected  flight  was  the  leading  flight,  then  the  second  flight 
might  also  be  significantly  delayed  if  the  lead  flight  held  on  the  taxiway  for  the 
ramp  to  become  clear.    Observations  made  during  the  previous  O'Hare  Operations 
Analysis  indicated  that  the  average  time  for  taxi  out  of  the  ramp  area  was  54 
seconds.    Thus,  if  it  was  assumed  for  simplicity  that  all  the  departures  shown  in 
Figure  3-8  are  ready  to  taxi  and  that  the  aircraft  on  the  Inner  are  held,  then  it 


Figure  3-8.     Example  of  Possible  Ramp  Area  Congestion  Problen 
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could  require  a  minimum  of  216  seconds  (slightly  over  3-1/2  minutes)  before  an 
arrival  could  enter  the  ramp  area  to  taxi  to  an  inner  gate.    If  any  of  the  departures 
were  only  starting  their  engines  (observed  engine  start  time  =  64  seconds)  this 
delay  could  be  even  longer. 

To  avoid  this  situation  a  final  logical  check  on  the  total  activity  level 
of  the  ramp  is  proposed  for  flights  requesting  pushback  for  which  no  other  inter- 
departure  conflicts  have  been  determined.    If  there  are  less  than  N  departures 
active  in  the  ramp,  where  N  is  a  system  parameter, ,  then  it  could  be  feasible  to 
allow  the  pushback;  if  not,  a  conflict  exists.    An  estimate  of  a  practical  value  of 
this  parameter  N  is  derived  as  follows.    It  is  assumed  that  on  the  average  out- 
bound flights  are  equally  likely  to  have  an  origination  gate  in  the  outer  or  inner 
portion  of  the  ramp  area.    Similarly,  on  the  average,  inbound  flights  are  likely  to 
have  a  destination  gate  in  the  outer  or  inner  portion  of  the  ramp  area.    Thus,  on 
the  average  an  inbound  is  likely  to  have  a  gate  ahead  of  N/2  of  the  outbound  flights. 
As  will  be  noted  in  the  description  of  the  Outbound-Inbound  Conflict  Manage- 
ment function  logic  the  inbound  flight  would  be  given  priority.      Therefore, 
it  would  be  delayed  only  by  those  N/2  aircraft  ahead  of  its  destination  gate  (about 
N/2).    If  it  is  assumed  these  N/2  flights  were  just  beginning  engine  start,  then  an 
inbound  flight  would  face  an  average  maximum  delay  (D,,)  in  seconds  of 

DM  =  f  (VV 

where  t    and  t     are  the  average  engine  start  and  taxi  out  times.    Similarly,  if  it 
is  assumed  that  these  N/2  flights  were  beginning  to  taxi  out,  then  the  inbound  flight 
would  face  an  average  minimum  delay  (D    )  in  seconds  of 

N 

Substituting  the  values  for  t    and  t     observed  at  O'Hare  then, 

N 
D      =  —  (64  +  54)  =  59N  seconds 


of  N. 


Table  3-2  lists  the  values  of  these  delay  extremes  for  several  values 


Table  3-2.    Potential  Maximum  and  Minimum  Inbound  Delays 
for  N  Outbounds  in  the  Ramp  Area 


N 

DM  (SGC) 

D  (sec) 
m 

2 

118 

54 

3 

177 

81 

4 

236 

108 

5 

295 

135 

From  this  table  it  can  be  seen  that  for  N  greater  than  4  even  the  mini- 
mum potential  delay  (D    )  becomes  excessive,  i.e.  ,  over  two  minutes.    Thus,  it 
would  appear  that  a  value  of  N  =  4  represents  a  practical  parameter  for  limiting 
the  number  of  active  outbound  flights  in  a  single  Positive  Ramp  Control  area. 

Before  a  flight  may  be  cleared  to  advance  to  the  next  higher  state  of 
readiness,  it  is  also  necessary  to  determine  whether  this  action  would  result  in  a 
conflict  with  flights  inbound  to  the  ramp.    Thus,  all  subject  flights  satisfying  the 
Inter-Departure  Conflict  Management  criteria  are  transferred  to  the  Outbound- 
Inbound  Conflict  Management  function. 

When  an  inter-departure  conflict  is  determined,  the  conflict  condition 
would  be  displayed  to  the  tower  (Ramp  Control)  personnel  and  the  processing  for 
the  flight  returned  to  the  originating  function. 

3.2.3.5        Handoff  to  Ground  Control  Departure  Q  (Function  E) 

The  functional  flow  for  Handoff  to  Ground  Control  Departure  Q  is 
illustrated  in  Figure  3-9.    IFR  air  carrier  flights  will  enter  this  function  from 
the  Maintain  Outbound  Ramp  Q  function.    VFR  and  IFR  general  aviation  will  enter 
this  function  from  the  Flight  Clearance  Delivery  function. 
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Figure  3-9. 


Handoff  to  Ground  Control  Departure  Queue  ■ 
Functional  Flow  Diagram 


For  flights  in  positive  ramp  control  areas  it  will  be  necessary  for  the 
ATCT  (Ramp  Control)  personnel  to  enter  the  handoff  into  the  system  for  transfer 
of  the  flights  to  the  Ground  Control  Departure  Q.    As  air  carrier  flights  enter  the 
Q,  the  Gate  Schedules  data  will  be  updated  to  indicate  that  the  gates  from  which 
they  departed  are  available  for  arrival  flights. 

3.2.3.6        Verify  Gate  Assignment  (Function  F) 

The  functional  flow  for  Verify  Gate  Assignment,  the  first  function  for 
arrivals,  is  illustrated  in  Figure  3-10.  This  function  and  the  following  functions 
are  applicable  only  to  air  carrier  arrival  flights. 

An  applicable  flight  will  be  entered  into  the  Ground  Control  Arrival  Q 
List  by  the  Local  Control  System*.    When  this  occurs,  the  Gate  Schedule  data  will 
be  accessed  to  determine  the  flight's  assigned  gate  and  the  availability  of  the  gate 
for  the  flight.    The  Gate  Schedule  data  may  have  been  updated  for  one  or  more  flights 
when  gate  changes  are  known  in  advance  by  airlines  flight  operations. 

If  the  flight's  gate  is  available,  the  gate  assignment  and  its  availability 
will  be  transmitted  to  the  Ground  Control  System  for  use  in  routing  of  the  flight 
and  communication  to  the  pilot.    A  gate  may  be  considered  to  be  available  if  it  is 
currently  open  (i.e.,  no  flight  on  the  gate)  or  if  the  flight  at  the  gate  is  in  an  active 
status  (i.e.  ,  in  Pushback,  Ready-to-Taxi,  or  Handoff  to  Ground  Control  Departure 
Q  status).    Airline  decisions  will  also  determine  gate  availability. 

If  the  flight's  gate  is  not  available,  a  gate  assignment/ availability 
request  message  will  be  transmitted  to  the  appropriate  airline's  flight  operations. 
Flight  operations  will  enter  the  revised  gate  assignment  and/or  delay  in  availa- 
bility.    This  data  will  update  the  Gate  Schedules  Data  and  will  be  transmitted  to 
the  Ground  Control  System  for  use  in  flight  routing  and  communi cation  to  the 
pilot. 

*  Refer  to  Section  3.4 
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Figure  3-10.    Verify  Gate  Assignment  -  Functional  Flow  Diagram 


3.  2.  3.  7         Monitor  Inbound  Ramp  Q  (Function  G) 

The  functional  flow  for  Monitor  Inbound  Ramp  Q  is  illustrated  in  Figure 
3-11.     Flights  will  enter  this  function  at  some  time  after  the  performance  of  the 
Verify  Gate  Assignment  function.    This  will  be  accomplished  through  the  entry 
of  the  flight  into  the  Inbound  Ramp  Q  by  the  Ground  Control.    It  is  at  this  time  that 
checks  will  be  started  for  Ramp  entrance  conflicts  (see  GCS). 

For  flights  scheduled  for  gates  in  non-Positive  Ramp  Control  areas, 
no  processing  will  occur  until  the  flight  docks  or  parks  at  its  gate. 

For   flights  scheduled  for  gates  in  Positive  Ramp  Control  areas,  the 
Ground  Control  System  will  also  transmit  a  ramp  status  request.     The  Outbound- 
Inbound  Conflict  Management  function  would  be  called  to  determine  whether  a  con- 
flict exists.    If  a  conflict  is  determined  and  the  flight  is  still  in  the  taxiway  net- 
work, a  ramp  conflict  message  would  be  transmitted  to  the  Ground  Control  System. 
If  the  flight  is  not  on  taxiway  (i.e.,  it  is  holding  in  a  portion  of  the  ramp  surface 
clear  of  the  gate  ramp  traffic),  then  it  will  be  re-entered  for  service  by  the  Out- 
bound-Inbound Conflict  Management  function  in  its  next  cycle. 

If  no  conflict  is  determined,  the  flight  would  be  transferred  to  the 
Clear  to  Gate  function,  i.e.,  Handoff  by  Ground  Control  System. 

A  short  time  later  the  flight  will  have  taxied  through  the  ramp  area 
and  docked  or  parted  at  its  gate.    When  this  occurs,  it  will  be  entered  into  the 
system.    This  will  delete  the  flight  from  the  Inbound  Ramp  Q  and  will  update  the 
Gate  Schedules  data  to  show  the  gate  as  occupied. 

As  in  the  case  of  the  entry  of  a  pushback  request,  the  entry  that  the 
flight  docked/parked  could  be  made  by  the  ATCT  (Ramp  Control)  or  airlines 
flight  operations  personnel.    The  latter  approach  would  be  more  desirable  from 
the  points  of  view  of  minimizing  tower  controller  communications  and  data  entry 
workload  and  avoiding  voice  channel  congestion  in  the  ramp  area.    However,  it 
would  again  require  agreement  by  the  airlines. 


-X-  May  be  entered  by  tower  or 
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Figure  3-11.    Monitor  Inbound  Ramp  Queue  -  Functional  Flow  Diagram 


3.  2.  3.  8        Clear  to  Gate  (Function  H) 

The  function  flow  for  Clear  to  Gate  is  illustrated  in  Figure  3-12.    This 
function  applies  only  to  arrivals  scheduled  for  gates  in  Positive  Ramp  Control 
areas.    The  flight  will  enter  this  function  from  the  Monitor  Inbound  Ramp  Q  func- 
tion when  no  conflict  has  been  determined  for  the  ramp  area. 

If  the  flight  is  still  in  the  taxi  way  network,  a  ramp  available  message 
will  be  transmitted  to  the  Ground  Control  System  for  use  by  Ground  Control.    If 
the  flight  is  holding  in  an  area  of  the  ramp  surface,  the  ATCT  (Ramp  Control) 
will  clear  the  flight  to  its  gate  and  enter  this  clearance  into  the  system. 

In  either  case  the  Inbound  Ramp  Q  will  be  updated  to  show  the  flight 
status  as  cleared  to  the  gate.    This  in  effect  reserves  the  ramp  area  from  its 
entrance  to  the  point  of  the  destination  gate  for  the  exclusive  use  of  the  arrival 
flight. 

The  flight  will  then  be  transferred  back  to  the  Monitor  Inbound  Ramp 
Q  to  wait  for  the  report  of  its  arrival  at  the  gate. 


*  Waiting  for  Flight  to 
Dock  /Pork. 


Figure  3-12.    Clear  to  Gate  -  Functional  Flow  Diagram 


3.  2.  3.  9         Outbound-Inbound  Conflict  Management  (Function  J) 

The  functional  flow  for  Outbound -Inbound  Conflict  Management  is  il- 
lustrated in  Figure  3-13.     This  function  applies  to  both  outbound  and  inbound  flights 
served  by  gates  in  Positive  Ramp  Control  areas.    Outbounds  will  enter  this  func- 
tion from  the  Inter-Departure  Conflict  Management  function.    Inbounds  will  enter 
from  the  Monitor  Inbound  Ramp  Q  function. 

As  in  the  case  of  the  Inter-Departure  Conflict  Management  function,  the 
logical  flow  can  be  readily  followed  once  the  basic  concepts  for  the  process  are 
understood.    Therefore,  these  concepts  are  described  here  rather  than  the  detailed 
functional  flow  sequence. 

The  concept  of  one  gate  ahead  of  another  discussed  previously  in  con- 
nection with  the  Inter-Departure  Conflict  Management  function  applies  here  as  well. 
In  this  case,  it  applies  to  the  destination  gate  of  the  inbound  flights  in  relation  to 
the  origination  gate  of  outbound  flights. 

In  addition,  the  basic  approach  of  defining  a  conflict  as  a  situation  that 
would  impede  the  flow  of  a  flight  in  a  higher  priority  status  applies  here  as  well. 
For  arrival  flights  the  priority  statuses  defined  here,  in  highest  order  first, 
include: 

1.  Cleared  to  Gate 

2.  Within  T     seconds  of  arrival  at  the  appropriate  turnoff  from  the 
the  taxi  network  -  second  attempt  at  ramp  entry* 

3.  Holding  in  ramp  area  for  clearance  to  taxi  to  gate 

4.  Entering  last  link  in  taxi  network  prior  to  approaching  the  turn- 
off  intersection  (more  than  T^  seconds  from  intersection  )  - 
Second  attempt  at  ramp  entry 


*T^  is  a  system  parameter  which  is  a  highly  reliable  prediction  of  the  flight's 
arrival  at  the  turnoff  intersection.    The  estimation  of  the  value  of  T^  is  discussed 
in  the  Ground  Control  System  section. 
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Figure  3-13.    Outbound-Inbound  Conflict  Management  -  Functional  Flow  Diagram 


5.  Within  T^  seconds  of  arrival  at  the  appropriate  turnoff  intersection  - 
first  attempt  at  ramp  entry 

6.  Entering  last  link  prior  to  approaching  turnoff  intersection  -  first 
attempt  at  ramp  entry 

Departure  flights  are  compared  against  the  status  of  flights  in  the  In- 
bound Ramp  Q.    Arrival  flights  are  compared  against  the  existence  of  flights  in  the 
Ground  Control  Departure  Q  and  the  status  of  flights  in  the  Outbound  Ramp  Q. 

Flights  in  the  Inbound  Ramp  Q  for  a  given  ramp  would  be  acted  on  by 
this  function  in  the  order  of  their  priority  status. 

Flights  in  the  Ground  Control  Departure  Q  are  given  priority  over  flights 
in  the  Inbound  Ramp  Q . 

When  the  gate  for  an  active  departure  in  the  Outbound  Ramp  Q  (i.e., 
the  flight  is  in  pushback  or  ready-to-taxi  status)  is  ahead  of  the  gate  for  the  arrival, 
then  a  conflict  exists.     The  arrival  would  be  returned  to  the  Monitor  Inbound  Ramp 
Q  function  and  transmission  of  ramp  conflict  message  to  the  Ground  Control  System, 
as  applicable. 

When  the  gate  for  a  non-active  departure  is  ahead  of  the  arrival's  gate 
(i.  e. ,  flight  is  in  pushback  request  status),  the  arrival  is  given  priority.    The  ar- 
rival is  transferred  to  the  Clear  to  Gate  function  for  transmission  of  the  clearance. 
A  conflict  message  is  displayed  to  Ramp  Control  and  the  flight  is  returned  to  the 
Pushback  Clearance  Function  to  be    re-entered  into  the  next  conflict  processing 
cycle.    However,  when  the  destination  gate  for  the  arrival  is  ahead  of  the  gate  for 
a  departure  in  this  status,  then  no  conflict  exists  and  both  flights  may  be  cleared 
to  proceed  (the  arrival  to  taxi  to  the  gate  and  the  departure  to  pushback). 

When  the  destination  gate  for  the  arrival  is  ahead  of  the  gate  for  an 
active  departure,  the  arrival  is  normally  given  priority.    The  exception  occurs 
when  the  arrival  is  in  the  lowest  priority  status  and  the  departure  is  in  the  ready- 
to-taxi  status.    In  this  situation,  priority  would  be  given  to  the  departure.    The 
rationale  for  this  priority  is  based  upon  these  considerations: 


1.  It  is  most  desirable  to  keep  the  outbound  traffic  flowing  in  a 
reasonably  constant  stream  to  the  runways  in  order  that  the  opti- 
mum capacity  of  runways  can  be  achieved. 

2.  Delay  of  competing  departures  may  also  result  in  delays  to  other 
departures  in  the  ramp. 

3.  During  busy  periods  there  may  be  another  arrival  with  the  compet- 
ing  departure's  gate  as  its  destination  and  the  gate  should  be 
cleared  as  rapidly  as  possible. 

In  all  situations,  Ramp  Control  would  be  given  a  positive  display  of  the 
conflict  or  no  conflict  exists  for  each  ramp  and  flights  within  the  ramp. 

3.  2.  3. 10       Controller  Intervention/Override  of  Capabilities 

The  descriptions  of  the  performance  of  the  various  RCS  functions 
provided  in  the  preceding  paragraphs  represent  the  basic  logical  flows  for  these 
functions.    As  in  any  other  semi-automated  real-time  control  system,  especially 
an  air  traffic  control  system,  the  capabilities  for  intervention  in  or  override  of 
system  logical  decisions  must  be  inherent  in  the  system  design.    In  the  case  of 
the  Ramp  Control  System  concepts  the  ATCT  (Ramp  Control)  personnel  must  have 
the  functional  capabilities  to  review  the  results  or  cues  of  system  processing  in 
relation  to  the  overall  situation  to  determine  when  such  intervention  is  advanta- 
geous.   This  intervention  could  take  the  form  of  decisions: 

1.  To  deny  a  clearance  to  pushback  or,  conversely,  to  authorize 
pushback  in  contradiction  to  control  cues  presented  by  the  system. 

2.  To  accomplish  a  handoff  of  an  outbound  flight  to  ground  control  in 
contradiction  to  control  cues  (or,  conversely,  to  delay  a  handoff). 

3.  To  deny  a  clearance  (or,   conversely,  to  issue  a  clearance)  for  an 
inbound  flight  to  taxi  to  its  gate. 

4.  To  emphasize  service  to  outbound  or  inbound  flights  in  general 
based  upon  the  traffic  situation. 

Accomplishment  of  these  capabilities  must  be  afforded  in  the  nature  of 
the  information  (control  cues  and  other  situation  data)  displayed  to  the  Ramp  Con- 
trol position  by  the  RCS  as  well  as  the  data  entry/retrieval  features  of  the  system. 


As  an  example,  consider  a  situation  where  a  flight  indicates  it  is 
ready  to  taxi  and  the  flight  on  a  gate  ahead  of  it  is  in  pushback  but  not  yet  ready  to 
taxi.    In  this  situation,  the  logic  of  Inter-Departure  Conflict  Management  function 
would  determine  that  a  conflict  exists  and  this  information  would  be  displayed  to 
Ramp  Control.    However,  depending  on  the  types  of  aircraft  involved  and  the  exist- 
ence or  absence  of  aircraft  on  gates  opposite  to  that  of  the  pushback,  it  might 
actually  be  possible  for  the  requesting  flight  to  safely  taxi  around  the  pushback. 
In  the  observation  of  operations  and  analysis  of  the  communications  of  ground  con- 
trol personnel  at  O'Hare  it  was  noted  that  these  personnel  may  ask  a  pilot  if 
he  has  room  to  pass  a  blocking  flight.    If  the  pilot  responded  affirmatively  he  would 
receive  the  appropriate  taxi  instructions.    This  was  observed  for  both  the  outbound 
and  inbound  Ground  Control  positions.    Therefore,  if  the  RCS  provided  sufficient 
information,  Ramp  Control  could  be  capable  of  determining  whether  such  a  situ- 
ation exists  or  to  coordinate  with  the  requesting  flight  on  the  situation  in  order  to 
decide  whether  to  accept  or  override  the  displayed  control  cue. 

The  nature  of  potential  information  display  features  that  could  provide 
the  required  capabilities  for  controller  intervention/override  will  be  discussed  in 
paragraph  3.  3.4. 


3.  2.  4  Operational  Requirements 

Implementation  of  an  RCS  will  be  influenced  by  the  operational  environ- 
ment of  potential  airports.    This  includes  the  physical  configuration  of  the  airport 
facilities,  traffic  volume,  and  environmental  conditions  under  which  operations  are 
conducted. 

3.  2.  4.  1         Physical  Configuration  of  Airport  Facilities 

In  general,   Positive  Ramp  Control  would  primarily  apply  to  the  passen- 
ger terminal  ramp  area.     The  most  predominant  physical  characteristic  of  a  termi- 
nal configuration  that  would  tend  to  necessitate  Positive  Ramp  Control  is  one  involv- 
ing wings  or  fingers  along  which  gates  are  located.    Where  these  wings  or  fingers 
are  basically  parallel  and  are  sufficiently  close  to  prohibit  movement  of  more  than 
one  flight  at  a  time  past  aircraft  parked  at  gates  on  both  wings,  then  Positive  Ramp 
Control  is  likely  to  be  required.     In  addition,  when  the  wings  are  long,   i.  e.  ,  more 
aircraft  gates  in  a  given  ramp  area,   Positive  Ramp  Control  becomes  more  desir- 
able to  avoid  conflicts  between  flight  operations.     The  amount  of  separation  between 
parallel  wings  at  which  Positive  Ramp  Control  would  not  be  required  is  also  depend- 
ent on  the  types  of  aircraft  operating  at  an  airport.     Airports  having  a  significant 
volume  of  wide-bodied  aircraft  traffic  would  require  wider  separation  between  par- 
allel wings  than  those  where  the  traffic  is  primarily  non-heavy  aircraft. 

Other  terminal  area  configurations  in  which  Positive  Ramp  Control 
may  be  required  include  cases  wherein: 

•  A  physical  structure  (such  as  a  building  or  fence)  is  parallel  or 
opposite  to  the  terminal  gates. 

•  An  aircraft  parking  area,  for  non-air-carrier  aircraft,   e.  g. , 
general  aviation  or  military  aircraft,  opposite  to  the  terminal 


A  terminal  building  configuration  other  than  parallel  wings  where 
the  ramp  area  entrance/exit  throat  does  not  permit  simultaneous 
passage  of  two  aircraft. 


•  A  multiple  terminal  building  configuration  (e.  g. ,  J.  F.  Kennedy  and 
Los  Angeles  International  Airports)  where  the  distance  between  the 
terminals  does  not  permit  simultaneous  movements  of  two  aircraft. 

A  ramp  area  configuration  involving  a    Y      configuration  of  the  termi- 
nal wings  represents  a  special  situation.     Depending  on  the  length  of  the  wings  and 
the  angle  between  them,  there  may  be  sufficient  space  for  independent  aircraft 
movement  at  the  outer  portion  of  the  ramp  area.     However,   it  is  almost  a  cer- 
tainty that  Positive  Ramp  Control  would  be  required  in  some  portion  of  the  inner 
ramp  area  up  to  a  point  where  the  distance  between  the  wings  permits  multiple  air- 
craft movements. 

At  some  airports  Positive  Ramp  Control  might  even  be  required  in 
cargo  or  hangar  areas.     Delays  in  the  operation  of  aircraft  in  these  areas  may 
not  be  as  critical  as  delays  for  aircraft  in  the  passenger  terminal.     However,  de- 
pending on  the  interface  of  these  areas  with  the  taxiway  network,   delays  in  the 
movement  of  aircraft  into  or  out  of  the  areas  could  cause  delays  in  the  taxiway 
network.     Such  situations  could  exist  when  access/egress  from  these  areas  to  a 
portion  of  taxiway  network  is  by  single  taxi  ramp  and  where  the  cargo/hangar 
traffic  mixes  with  the  other  airport  traffic  in  that  portion  of  the  taxiway  network. 
Examples  of  such  situations  at  O'Hare  include: 

1.  The  intersection  of  taxiway  referred  to  as  Hangar  Alley  with  the 
Scenic  Taxiway,  which  carries  departure  traffic  to  runway  14L, 
northwest  of  the  ATCT. 

2.  The  intersection  of  the  same  hangar  area  taxiway  with  the  runway 
14R/32L  parallel  taxiway,  which  carries  departure  traffic  to  14R 
or  arrival  traffic  from  32L,   southwest  of  the  ATCT. 

3.  The  intersection  of  cargo  area  ramp  with  the  cargo  taxiway,  which 
carries  departure  traffic  for  22L  or  27L  or  arrival  traffic  from  9R, 
southeast  of  the  ATCT. 

During  the  O'Hare  Operations  Analysis  it  was  observed  that  traffic 
movement  to  or  from  the  cargo  or  hangar  required  coordination  between  Inbound 
Ground  and  Outbound  Ground  to  control  traffic  flow  at  these  intersections. 


Similar  situations  may  exist  at  other  airports,  necessitating  Positive 
Ramp  Control  for  the  ramp  areas  to  avoid  traffic  flow  problems  in  the  taxiway 
network. 

3.  2.  4.  2        Ramp  Area  Traffic  Volume 

The  airport  ramp  area  configurations  discussed  above  give  rise  to 
potential  ramp  area  traffic  conflicts.     However,  the  requirement  for  implementa- 
tion of  Positive  Ramp  Control  in  such  areas  is  also  dependent  on  the  volume  of 
traffic  served  by  the  area.    Obviously  the  higher  the  traffic  operations  rate  the 
greater  the  potential  for  traffic  flow  conflicts.    An  assessment  is  made  of  the 
traffic  conditions  for  which  Positive  Ramp  Control  is  required  as  well  as  the 
capacity  requirements  for  the  Ramp  Control  System. 

Table  3-3  provides  a  summary  of  ramp  congestion  associated  delays 
observed  at  O'Hare.     The  table  indicates  the  number  of  arrivals  and  departures  to 
various  ramp  areas  during  twelve  observation  periods,  the  computed  hourly  oper- 
ations rate  for  the  ramp  areas,  the  ratio  of  arrivals  to  departures  for  the  observa- 
tion period,  and  the  percent  of  aircraft  operations  experiencing  delays. 

The  percentage  of  arrivals  delayed  included  aircraft  which  were  held 
momentarily  within  the  ramp  area  as  well  as  those  which  were  held  on  the  taxiways 
for  access  to  the  ramp  areas.    The  former  group  represents  holds  noted  during  the 
observation  periods.    The  latter  represents  an  estimate  of  the  number  of  aircraft 
held  based  upon  the  results  of  taxi  hold  analysis  performed  utilizing  the  ASDE 
films  taken  by  TSC  and  CSC.     This  analysis  indicated  that  approximately  20  percent 
of  the  arrival  aircraft  holds  were  due  to  ramp  congestion;  i.  e.  ,  the  arrival  was 
held  on  the  inner  or  outer  taxiway  or  at  an  intersection  of  the  outer  and  crossing 
taxiways. 

The  percentage  of  departure  flight  delays  represents  momentary  holds 
of  aircraft  in  the  ramp  area  after  they  had  begun  to  taxi  from  their  pushback  posi- 
tion.    It  does  not  include  delays  in  flight  pushback  by  airlines  (United  or  American) 
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ramp  control  personnel  due  to  competing  traffic  or  delays  in  issuing  of  taxi  in- 
structions because  Outbound  Ground  was  aware  that  the  flight  could  not  taxi  due 
to  competing  traffic.     These  delays  could  not  be  determined  due  to  limitations  of 
data  collection  and/or  analysis. 

The  limited  amount  of  data  available  in  Table  3-3  does  not  permit  ana- 
lytic determination  of  any  parametric  relationships.     However,   a  number  of  sig- 
nificant observations  can  be  made  from  examination  of  this  data: 

1.  The  percent  of  operations  delayed  tends  to  be  greater  as  the  Ar- 
rivals/Departure ratio  is  less  than  or  approaches  1.  0.     The  ramp 
area  service  times  observed  in  the  O'Hare  Operations  Analysis 

(i.  e. ,  average  times  of  200  seconds  for  departures  and  75  seconds 
for  arrivals)  would  tend  to  support  this  observation. 

2.  The  major  exception  to  this  observation  occurs  for  the  first  entry 
in  the  table.    However,  the  traffic  level  for  these  observation  peri- 
ods is  significantly  lower  than  for  other  periods. 

3.  For  periods  when  the  Arrivals/Departure  ratio  exceeds  1.  0  the 
percentage  of  all  flights  delayed  increases  with  the  traffic  opera- 
tions rate. 

4.  The  percentage  of  traffic  delayed  exceeds  ten  percent  for  all  but 
the  one  period  with  the  low  traffic  operations  rate. 

Based  upon  this  data  two  conclusions  are  drawn  regarding  the  require- 
ments for  the  Ramp  Control  System: 

1.  The  system  should  be  designed  for  a  capacity  of  20,  and  possibly 
up  to  25,  operations  per  hour  for  each  terminal  building  ramp  area. 

2.  Positive  Ramp  Control  should  be  implemented,  when  the  traffic 
volume  is  equal  to  or  exceeds  14  operations  per  hour  in  a  ramp 
area  with  a  configuration  offering  a  potential  for  traffic  flow  con- 
striction. 

3.  2.  4.  3         Environmental  Factors 

Earlier  in  this  section  one  of  the  criteria  cited  for  classification  of  a 
ramp  area  as  requiring  Positive  Ramp  Control  was  the  lack  of  sufficient  space  for 


simultaneous  independent  operations  of  two  outbound  aircraft  or  an  outbound  and  an 
inbound  aircraft  with  a  sufficient  degree  of  safety  during  periods  of  poor  operating 
conditions.     This  is  based  on  the  assumption  of  reduced  pilot  capability  for  visual 
reference  to  other  aircraft,  or  physical  structures.     This  factor  suggests  some 
qualifications  of  the  discussions  in  the  preceding  paragraphs. 

Consider  first  the  potential  impact  in  areas  where  the  terminal/ramp 
configuration  would  not  normally  require  Positive  Ramp  Control.     This  would  be 
because  the  terminal/ramp  area  configuration  does  not  include  any  physical  fea- 
tures tending  to  constrain  traffic  movement  (e.  g.  ,  terminal  fingers,  narrow  throat 
for  ramp  area  entrance/exit)  or  because  the  distance  between  constraining  features 
is  sufficient  to  permit  multiple  flight  operations.     Under  Category  II  and  lower 
operating  conditions  pilot  visibility  may  be  sufficiently  reduced  so  that  wing  tip 
clearance  requirements  would  have  to  be  increased  to  assure  an  adequate  safety 
margin.    Thus  a  ramp  area  that  was  not  a  candidate  for  Positive  Ramp  Control  under 
good  visibility  conditions  might  require  Positive  Ramp  Control  under  poor  operat- 
ing conditions.     In  addition,   reduced  pilot  forward  visibility  under  these  conditions 
may  necessitate  greater  care  at  the  ramp  area  interface  with  the  taxiway  network, 
particularly  where  outbound  and  inbound  aircraft  paths  might  cross  due  to  their 
points  of  entrance  to  or  exit  from  the  taxiway  network. 

Consider  next  the  potential  impact  on  areas  which  would  not  normally 
require  Positive  Ramp  Control  because  of  a  low  traffic  operations  rate.    Reduced 
pilot  visibility  under  poor  operating  conditions  would  require  greater  care  in  con- 
trolling the  movements  of  aircraft  into  and  out  of  the  ramp  area.    As  an  example, 
the  O'Hare  Operations  Analysis  included  a  period  of  Category  II  conditions  during 
which  visibility  dropped  briefly  to  effectively  Category  Ilia  conditions.     Throughout 
this  period,   visibility  of  the  low  level  of  aircraft  operations  in  the  terminal  ramp 
areas  from  the  ATCT  was  non-existent.     Therefore,  neither  Outbound  nor  Inbound 
Ground  had  any  visual  references  to  the  relationship  between  departure  and  arrival 
traffic  for  the  same  ramp  area  on  which  to  control  flight  movements  for  the  area. 


During  the  brief  period  in  which  visibility  dropped  to  effectively  Cate- 
gory Ilia  conditions  a  pilot  in  one  ramp  area  was  given  his  taxi  clearance  by  Out- 
bound Ground.     Just  prior  to  that  another  departure  flight  from  the  same  ramp 
area  had  been  given  his  taxi  clearance  by  Outbound  Ground.     The  pilot  of  the  later 
departure  informed  Outbound  Ground  that  he  did  not  have  sufficient  visibility  to 
determine  the  location  of  the  previous  departure  ahead  of  him  and  that  he  would 
not  taxi  until  Outbound  Ground  could  advise  him  of  the  position  of  the  previous  de- 
parture.    Outbound  Ground  had  to  contact  the  previous  departure  to  determine  that 
it  was  clear  of  the  ramp  area  and  convey  that  information  to  the  concerned  pilot, 
who  then  indicated   that  he  was  starting  to  taxi. 

From  the  above  discussion  it  would  appear  that  under  poor  visibility 
conditions  it  could  become  necessary  or  desirable  to  implement  Positive  Ramp 
Control  in  areas  that  would  not  normally  be  controlled  under  good  visibility  condi- 
tions.    Therefore,  the  design  of  the  ASTC  system  should  permit  the  flexibility  and 
capacity  to  accomplish  Positive  Ramp  Control  in  nominally  Non- Positive  Ramp 
Control  areas  when  operating  visibility  is  sufficiently  reduced  to  make  such  control 
necessary. 


3.3  PRELIMINARY  DESCRIPTION 

This  section  describes  the  RCS  elements,  data  requirements,  data 
transmission  across  system  interfaces,  and  information  display  and  data  entry 
requirements  for  the  performance  of  the  RCS  functions. 

3.  3. 1  Overall  Characteristics 

The  overall  configuration  of  the  proposed  Ramp  Control  System  is 
illustrated  in  Figure  3-14.     The  RCS  components  include: 

ARTCC  (NAS)  Interface  Equipment 
TRACON  (ARTS)  Interface  Equipment 
Central  Data  Processing  Equipment 
Ramp  Control  Input /Output  Equipment 
Automatic  Gate  Status  Equipment 
Control  Communications  Equipment 

The  ARTCC  (NAS)  Interface  Equipment  would  provide  for  automated 
data  exchange  with  NAS  for  receipt  of  IFR  flight  clearances  and  delay  restrictions. 
The  TRACON  (ARTS)  interface  provides  for  receipt  of  available  beacon  codes  for 
VFR  departures.     Other  coordination  communications  between  the  Ramp  Control, 
NAS,  and  ARTS  personnel  would  be  via  voice  landline  facilities. 

The  Central  Data  Processing  Equipment  would  be  used  for: 

•  Reception  and  integration  of  data  received  from  ARTS  and  NAS 
into  the  system  data  base. 

•  Maintenance  of  the  data  base  required  for  the  performance  of  the 
Ramp  Control  System  functions. 

•  Management  of  the  interface  with  airlines  flight  operations,  in- 
cluding reception  and  integration  of  data  entered  via  the  Auto- 
matic Gate  Status  Equipment  (AGSE)  and  transmission  of  data 
requests  to  the  AGSE. 

•  Processing  of  system  data  to  accomplish  the  functions  of  the  sys- 
tem, including  the  determination  of  ramp  area  traffic  flow  con- 
flicts. 


•  Management  of  the  interface  with  the  Ramp  Control  Input/Output 
Equipment,  including  reception  and  integration  of  data  entered 
via  that  equipment  and  generation  of  control  information/cue  dis- 
plays. 

The  Central  Data  Processing  Equipment  is  shown  in  Figure  3-14  as  an 

element  of  the  RCS.    It  is  probable  in  the  total  ASTC  system  configuration  that  it 

would  be  shared  among  the  Ground  Control  and  Local  Control  Systems  as  well. 

The  Ramp  Control  Input/Output  Equipment  would  provide  the  functional 
capabilities  for  the  man-machine  interface  between  Ramp  Control  personnel  and 
the  system  processing  features.    This  would  include: 

e  Preparation  of  flight  strips  (in  an  improved  format  as  discussed 

earlier)  for  use  in  delivering  flight  clearances  to  IFR  flights  and 
for  use  by  ATCT  personnel  in  a  backup  manual  mode  of  opera- 
tions. 

•  Presentation  of  the  appropriate  operational  situation  data  and  con- 
trol cues  information  for  use  by  Ramp  Control  personnel  in  assess- 
ing and  controlling  ramp  area  operations. 

•  Entry  of  flight  description,  status,  and  control  data  as  necessary. 

The  AGSE  would  provide  the  capabilities  for  the  man/machine  interface 
between  the  airlines'  flight  operations  personnel  and  the  system  data  processing  to 
accomplish  the  coordination  between  airlines'  flight  operations  and  the  ATCT.    This 
would  include: 

•  Presentation  of  status  information  on  flights  under  control  of  the 

ASTC  system.* 

0  Presentation  of  requests  for  information  on  the  availability  of 

gates  for  arrival  flights. 

o  Entry  of  data  on  anticipated  changes  in  gate  schedules  (assign- 

ments), to  be  used  in  response  to  requests  for  gate  availability 
from  arrival  flights. 


*It  is  considered  probable  that  airlines'  acceptance  of  some  of  the  proposed  RCS 
concepts  will  be  dependent  on  the  benefits  they  might  receive  through  availability 
of  data  on  the  status  of  their  flights  for  their  own  utilization. 


•  Entry  of  flight  status  data  necessary  for  initiation  of  service  to 
departures  in  Positive  Ramp  Control  areas  and  termination  of 
service  to  arrivals.  * 

It  should  be  noted  that,  although  not  specifically  shown  in  Figure  3-14, 
airlines  communications  facilities  also  constitute  an  element  of  the  RCS.    This  is 
based  on  the  assumption  that  pushback  clearances  and  reporting  of  aircraft  docking/ 
parking  will  be  accomplished  through  airlines  flight  operations. 

3.3.2  Data  Requirements 

Table  3-4  summarizes  the  data  requirements  for  the  performance  of 
the  control  functions  of  the  Ramp  Control  System.  The  required  data  items  are 
grouped  by  category: 

•  Data  pertaining  to  a  particular  flight. 

•  Data  pertaining  to  the  status  of  terminal  gates  (ramp  locations). 

•  Data  pertaining  to  departure  delay  restrictions. 

•  Data  specific  to  the  operational  environment  of  the  airport. 

The  control  functions  to  which  the  various  data  items  apply  are  in- 
dicated on  the  table.  Data  items  which  may  be  utilized  for  information  display 
purposes  are  also  indicated. 

Operations  data  would  be  maintained  in  the  system  data  base  in  a  num- 
ber of  working  files.    These  include: 

•  Departure  Flights  Data  File 

•  Outbound  Ramp  Q 

•  Ground  Control  Departure  Q 

•  Inbound  Ramp  Q 

•  Gate  Schedule  File 


*Based  on  the  assumption  that  entry  of  pushback  clearance  requests  and  flight 
docking/parking  status  is  made  by  the  airlines  to  minimize  voice  channel  loading 
and  controller  workload. 


Table  3-4.     Summary  of  Data  Requirements  for  Ramp  Control  System  Functions 
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DATA  ITEMS 

FLIGHT  DATA 

CALL  SIGN 

/ 

/ 

/ 

71 

/ 

/ 

/ 

/ 

/2 

AIRCRAFT  EQUIPMENT  TYPE 

./ 

/3 

/3 

/4 

/4 

/3 

BEACON  EQUIPMENT  TYPE 

/ 

ASSIGNED  BEACON  CODE 

/ 

CLEARED  ALTITUDE  (IFR) 

/ 

DESIRED  (CLEARED)  ALTITUDE  OUT 

OFTERMINAL  AREA  (VFR) 

/ 

FIRST  FIX  (IFR) 

/ 

/4 

DESIRED  DIRECTION  OF  FLIGHT  OUT  OF 

Z4 

TERMINAL  AREA  (VFR) 

/ 

CLEARED  ROUTE  (IFR) 

/ 

ORIGINATION  GATE  (RAMP  LOCATION) 

Z5 

/ 

/ 

/1 

/ 

/3 

/ 
/ 

DESTINATION  GATE  (RAMP  LOCATION) 

/5 

/ 

CURRENT  RAMP  DEPARTURE  (READI- 

NESS) STATUS 

S 

/ 

/1 

/3 

/ 

CURRENT  RAMP  ARRIVAL  STATUS 

/ 

/ 

/ 

TIME  OF  DEMAND  (ENTRY  INTO 

CURRENT  STATUS) 

/ 

/ 

/1 

•/ 

/ 

./ 

/ 

./2 

TERMINAL  GATE  (RAMP  LOCATION)  DATA 

/ 

/3 

z3 

/ 

/3 

GATE  (RAMP)  SCHEDULES 

CURRENT  GATE  (RAMP  LOCATION)  STATUS 

GATE  (RAMP  LOCATION)  AVAILABILITY  DELAY 

/ 

DEPARTURE  RESTRICTIONS  DATA 

/ 

RESTRICTED  DIRECTION(S)  OF  FLIGHT 

DELAY  RESTRICTION  FOR  EACH  DIRECTION 

OF  FLIGHT 

/ 

AIRPORT  OPERATIONS  DATA 

/ 

IFR  ALTITUDE  CLEARANCE  LIMIT(S) 

DEPARTURE  RUNWAY  ASSIGNMENT  CRITERIA 

Z6 

Z4'6 

AVAILABLE  (VFR)  BEACON  CODES 

/ 

NOTES 

1.  Required  for  Subject  (Requesting)  Departure  flight  and  Competing  departure  flights  in  same  Pi 

2.  Required  for  Subject  departure  (Arrival)  and  Competing  Arrival  (Departures)for  same  Positive 

3.  May  be  utilized  in  generating  display  for  Ramp  Control  to  permit  intervention/override  in  sysl 

4.  Required  for  inclusion  in  Ground  Control  Departure  Q  data  for  use  by  Ground  Control  System 

5.  Derived  for  this  function  from  Stored  Gate  (Ramp)  data. 


6.   Reflected  in  ii 


nof  ni 


runway  assignm 


n  flight  related  data  storage  and  outputs 


The  anticipated  data  contents  of  these  files  are  summarized  in 
Table  3-5. 

3.3.3  Interface/Data  Transfer  Considerations 

The  Ramp  Control  System  requires  data  transfer  with  the  external 
ATC  system  (ARTCC  and  TRACON)  as  well  as  with  the  Ground  Control  System  and 
Local  Control  System  components  of  the  total  ASTC  system. 

The  data  transfer  associated  with  the  ARTCC  interface  would  be  uni- 
directional from  the  ARTCC  (NAS)  to  the  Ramp  Control  System.    This  data  trans- 
fer would  include  specific  flight  and  general  operations  contraints,  i.  e.  ,  delay 
restrictions.     The  data  items  included  in  each  transfer  are  given  below. 

Specific  Flight  Data 

Call  Sign 

Proposed  Departure  Time 

Aircraft  (and  Beacon)  Equipment  Type 

Assigned  Beacon  Code 

Cleared  Altitude 

Departure  (First)  Fix 

Standard  Instrument  Departure  (SID)  Identification 

Cleared  Route  (all  components) 

General  Operations  Data 

Restricted  Direction  of  Flight  I 

(or  Departure  Fix)  I  For  each  restricted  direction  (or  fix) 

Applicable  Delay  Restriction 

Cancellations 

The  data  transfer  associated  with  the  TRACON  interface  would  be  uni- 
directional from  the  TRACON  (ARTS)  to  the  Ramp  Control  System.    This  data 
transfer  would  include  a  list  of  beacon  codes  available  for  assignment  to  VFR  de- 
partures. 


Table  3-5.    Summary  of  Proposed  Data  Contents  of  Primary  Ramp 
Control  System  Working  Files 


Data  Items 

Departure 
Flights 
Data  File 

Outbound 
Ramp  Q 

Ground 
Control 
Depar- 
ture Q 

Inbound 
RampQ 

Gate 

(Ramp) 

Schedules 

Data  File 

Flight  Call  Sign 

/ 

/ 

/ 

/ 

Aircraft  Equipment  Type 
(or  Class) 

/ 

1 
/ 

/ 

1 
/ 

Assigned  Beacon  Code 

/ 

/ 

Computer  Number 

2 

/ 

2 

/ 

2 
/ 

2 

/ 

Origination  Gate  (Ramp  Location) 

/ 

/ 

/ 

Destination  Gate  (Ramp  Location) 

/ 

Departure  (First)  Fix  or  Direc- 
tion of  Flight  (for  VFRs) 

/ 

/ 

Nominal  Runway  Assignment 

/ 

/ 

Departure  (Delay)  Restrictions 
(if  any) 

/ 

/ 

Current  Departure  (Readiness) 
Status 

/ 

/ 

Current  Ramp  Arrival  Status 

/ 

Time  of  Demand  (Entered  Status) 

/ 

/ 

/ 

Scheduled  Flight 

3 

/ 

Nominal  (Scheduled)  Departure 
Time 

3 
/ 

Nominal  (Scheduled)  Arrival 
Time 

3 

/ 

Current  Gate  Status 

/ 

Notes 

1.  Could  be  included  for  use  (display)  in  controller  intervention/override 
capability. 

2.  If  utilized  in  system  (as  in  NAS  and  ARTS). 

3.  For  each  flight  scheduled  for  use  of  Gate  (Ramp  Location). 


The  data  transfer  associated  with  the  LCS  interface  would  be  unidirec- 
tional from  the  Local  Control  System.    This  data  transfer  would  include  the  call 
sign  of  flights  entering  the  Ground  Control  Arrivals  Q  as  well  as  requests  for 
verification  of  Gate  Assignment  in  the  Ramp  Control  System. 

The  data  transfer  associated  with  the  GCS  interface  would  be  bidirec- 
tional between  the  Ramp  Control  and  Ground  Control  Systems.     These  data  trans- 
fers will  occur  as  entries  to  the  Ground  Control  Departure  Q,  Verify  Gate  Assign- 
ment, and  Monitor  Inbound  Ramp  Q  functions.    The  data  items  included  in  each 
transfer  are  given  below. 

1.  Handoff  to  Ground  Control  Departure  Q  (From  Ramp  Control  to 
Ground  Control) 

Flight  Call  Sign 

Aircraft  Equipment  Type  (or  Class) 

Assigned  Beacon  Code 

Computer  Number 

Origination  Gate 

Departure  (First)  Fix  or  Direction  of  Flight  (for  VFR) 

Nominal  Runway  Assignment 

Departure  (Delay)  Restrictions  (if  applicable) 

Time  of  Demand 

2.  Verify  Gate  Assignment  (From  Ramp  Control  to  Ground  Control) 

Flight  Call  Sign 

Destination  Gate  (Ramp  Location) 

Gate  (Ramp  Location)  Availability  Delay  (Zero  or  applicable 
delay  in  minutes) 

3.  Monitor  Inbound  Ramp  Q  (From  Ground  Control  to  Ramp  Control) 

Flight  Call  Sign 

Destination  Gate  (Ramp  Location) 

Ramp  Arrival  Status 

Time  of  Demand  (Entered  Status) 

Request  for  Ramp  Area  Availability 


4.      Monitor  Inbound  Ramp  Q  (From  Ramp  Control  to  Ground  Control) 

Flight  Call  Sign 

Destination  Gate  (Ramp  Location) 

Ramp  Area  Available  or  Unavailable  (conflict) 

3.3.4  Display  Considerations 

The  data  which  would  be  displayed  to  Ramp  Control  personnel  in  the 
ATCT  in  connection  with  the  performance  of  the  various  Ramp  Control  System 
functions  are  described  below. 

The  data  for  Clearance  Delivery  would  be  displayed  in  the  form  of  a 
flight  strip  prepared  by  the  FDEP  flight  strip  printer.     The  data  that  would  be  in- 
cluded in  either  IFR  or  VFR  flight  strips  are  listed  below. 

IFR  Flight  Strip 

Call  Sign 

Aircraft  (and  Beacon)  Equipment  Type 

Assigned  Beacon  Code 

Proposed  Departure  Time 

Cleared  Altitude  or  Altitude  Clearance  Limit  (if  appropriate) 

Departure  (First)  Fix 

Standard  Instrument  Departure  Identification 

Cleared  Route  (all  components) 

Origination  Gate  (Ramp  Location) 

Nominal  Runway  Assignment 

Departure  (Delay)  Restriction  (if  applicable) 

VFR  Flight  Strip 

Call  Sign 

Aircraft  (and  Beacon)  Equipment  Type 

Assigned  Beacon  Code 

Cleared  Altitude  (out  of  terminal  area) 

Cleared  Direction  of  Flight  (out  of  terminal  area) 

Nominal  Departure  Runway  Assignment 

Departure  Delay  Restriction  (if  applicable) 


The  data  display  necessary  for  control  of  flight  operations  associated 
with  the  Maintain  Outbound  Ramp  Q,  Pushback  Clearance,  Handoff  to  Ground  Con- 
trol Departure  Q,  and  Monitor  Inbound  Ramp  Q  functions  of  the  RCS  are  similar  in 
most  respects.    The  required  data  and  supplemental  data  items  which  could  be  dis- 
played are  summarized  in  Table  3-6.    Supplemental  data  includes  that  information 
which  would  be  displayed  to  Ramp  Control  for  evaluation  of  the  ramp  activity  situa- 
tion and  determination  of  the  appropriateness  of  intervention  in  the  operations  to 
override  system  recommended  control  cues. 

It  may  be  noted  that  in  each  case  the  supplemental  data  is  related  to: 

•  The  type  (or  class)  of  equipment  of  the  subject  requesting  flight. 

•  The  identity,  origination/destination  gate  (ramp  location),  and 
status  of  the  conflicting  outbound/inbound  flight(s) 

•  The  status  of  "opposing  gates". 

"Opposing  gates"  are  defined  as  those  gates  on  the  opposite  side  of  the 
ramp  area  from  that  of  the  origination/destination  gate  of  conflicting  outbound/in- 
bound flight(s). 

The  intent  of  the  supplemental  data  would  be  to  allow  the  Ramp  Control 
personnel  to  determine  whether  the  potential  exists  for  the  subject  (requesting) 
flight  to  maneuver  around  the  conflicting  flight.    If  such  a  potential  exists  Ramp 
Control  could  contact  the  pilot  of  the  subject  (requesting)  flight  to  determine  his 
assessment  of  the  potential.    If  the  pilot  indicated  that  such  a  maneuver  was  pos- 
sible, then  Ramp  Control  would  clear  the  pilot  to  proceed  under  his  own  respon- 
sibility.   This  process  (representing  shared  responsibility  in  flight  operations  con- 
trol as  noted  in  the  O'Hara  Operations  Analysis)  is  maintained  in  the  Ramp  Control 
System,  as  well  as  in  the  Ground  Control  System,  in  order  to  achieve  operational 
flexibility  and  to  avoid  unnecessary  delays. 


Summary  of  Data  Display  for  Flight  Operations  Control 
Functions  of  Ramp  Control  System 


Data  for  Display 

Maintain 
Outbound 
Ramp  Q 

Pushback 
Clear- 
ance 

Handoff 
to  Ground 
Control 
Depar- 
ture Q 

Maintain 
Inbound 
Ramp  Q 

Flight  Call  Sign 

R 

R 

R 

R 

Aircraft  Equipment  Type  (or  Class) 

S 

S 

S 

S 

Origination  Gate  (Ramp  Location) 

R 

R 

R 

A 

Destination  Gate  (Ramp  Location) 

A 

A 

R 

Current  Departure  (Readiness)  Status 

R 

R 

R 

A 

Current  Ramp  Arrival  Status 

A 

A 

R 

Time  of  Demand  (Entered  Status) 

R,A 

R,A 

R,A 

R,A 

Outbound  Conflict  (Hold  in  Position) 

R 

R 

No  Outbound  Conflict 

R 

R 

Inbound  Conflict  (Hold  in  Position  for 
Flight  Holding  in  Ramp  Area) 
or 

R 

No  Inbound  Conflict  -  Clear  to  Gate 

R 

Conflicting  Flight(s)  Call  Sign 

S 

S 

S 

Opposing  Gates  Status 

S 

S 

S 

R  =  Required  Data  Item 

S  =  Supplemental  Data  Item 

A  =  Available,  if  needed 


3.4  BENEFITS  ASSESSMENT 

The  benefits  assessment  considers  the  impact  of  the  RCS  on  aircraft 
traffic  delays  as  well  as  controller  functional  activities,  i.e.,  communications 
and  flight  strip  marking.    The  assessment  is  made  with  respect  to  values  obtained 
during  the  O'Hare  Operations  Analysis.    The  impact  is  first  determined  for  each 
control  function  of  the  Ramp  Control  System.    The  total  benefit  is  then  deter- 
mined as  the  sum  of  the  benefits  associated  with  each  control  function. 

3.4.1  Flight  Clearance  Delivery  Function 

The  potential  areas  of  impact  of  the  Flight  Clearance  Delivery 
function  are  listed  below. 

Delays 
None 

Controller  Communications 

•  Eliminate  communications  transactions  (CTs)  related  to 
obtaining  departure  gate  from  pilots. 

Manual  Activity 

•  Eliminate  marking  of  clearance  limit  by  Flight  Data  position. 

•  Eliminate  marking  of  departure  gate  by  Clearance  Delivery 

(Ramp  Control  in  system  concept). 

•  Eliminate  need  to  obtain  available  beacon  codes  via  ARTS 
keyboard  entry  by  Flight  Data. 

•  Eliminate  marking  of  departure  runway  assignment  by  Ground 
Control . 

•  Manual  preparation  of  a  flight  strip  for  a  VFR  departure  by 
Clearance  Delivery  will  be  replaced  by  entry  of  flight  data 
into  the  system  for  use  in  the  proposed  improved  flight  strip 
preparation. 


Based  upon  the  measurements  of  controller  activity  at  O'Hare,  the 
above  CTs  accounted  for  approximately  15  percent  of  the  communications  of  the 
Clearance  Delivery  position.    Therefore,  communications  channel  occupancy 
for  the  Clearance  Delivery  (Ramp  Control)  position  could  be  reduced  by  this 
amount. 

Based  upon  the  controller  manual  activity  analysis  the  above  ac- 
tivities represent  approximately 

•  27  percent  of  the  manual  activity  of  Flight  Data 

•  5  percent  of  the  manual  activity  of    Clearance  Delivery 

•  16  percent  of  the  manual  activity  of  Outbound  Ground 

Therefore,  the  manual  activities  workload  of  these  positions  could  be  reduced 
by  these  amounts. 

3.4.2  Maintain  Outbound  Ramp  Q 

The  potential  areas  of  impact  of  the  Maintain  Outbound  Ramp  Q 
function  are  listed  below. 

Delays 
None 

Controller  Communications 
None 

Manual  Activity 

•  Addition  of  need  to  enter  flight  status  (ready  to  taxi)  for 
air  carrier  departures  into  system  would  be  balanced  by 
elimination  of  controller  recording  of  time  of  request 
since  this  recording  would  be  automatically  accomplished 
by  the  system. 

•  Elimination  of  need  to  record  time  of  request  for  general 
aviation  flights  since  this  would  be  automatically  accom- 
plished at  the  time  the  flights  are  entered  into  the  system 
under  Flight  Clearance  Delivery  Function. 


Based  on  the  controller  activity  analyses  the  marking  of  ready-to- 
taxi  time  for  general  aviation  departures  represented  approximately  3.5  percent 
of  the  manual  activity  of  the  Clearance  Delivery  Position.    Thus,  the  manual 
activities  for  Clearance  Delivery  (Ramp  Control)  could  be  reduced  by  this  amount. 

3.4.3  Pushback  Clearance 

Delays 
None 

Controller  Communications 

Elimination  of  CTs  related  to  pilot  request  for  pushback  clear- 
ance as  these  would  be  entered  by  airlines. 

Manual  Activities 

Elimination  of  recording  of  time  of  request  for  pushback  clear- 
ance as  this  would  be  automatically  recorded  at  the  time  of  air- 
line request  entry. 

Based  on  controller  communications  activities  the  above  CTs 
represented  approximately  1  percent  of  the  communications  of  the  Clearance 
Delivery  position  at  O'Hare.    Therefore,  communications  channel  occupancy 
for  Clearance  Delivery  (Ramp  Control)  could  be  reduced  by  this  amount. 

Based  upon  the  O'Hare  Operations  Analysis,  flights  requiring 
pushback  clearance  represent  less  than  4  percent  of  the  total  operations.    The 
time  spent  in  marking  of  request  times  for  these  flights,  represents  approx- 
imately 1  percent  of  the  manual  activities  of  the  Clearance  Delivery  and  could 
be  eliminated  by  the  proposed  system  concept. 

3.4.4  Interdeparture  Conflict  Management 

The  areas  of  impact  for  this  function  by  the  nature  of  its  definition 
is  limited  to  reducing  delays  for  outbound  flights  (in  relation  to  other  outbound 
flights). 


The  O'Hare  Operations  Analysis  indicated  that  approximately  13  per- 
cent of  the  air  carrier  departures  experienced  a  delay  in  the  ramp  area,  for  an 
average  of  67  seconds.    Most  of  these  were  caused  by  blockage  by  other  depar- 
tures.   It  is  estimated  that  this  situation  accounted  for  75  percent  of  the  delays 
(the  remainder  are  due  to  ramp  area  arrivals). 

For  the  purposes  of  this  analysis  the  parameters  employed  in  the  pre- 
vious O'Hare  system  effectiveness  analysis  are  used  here:  120  operations  per  busy 
hour;  85  percent  air  carrier  traffic;  arrival/departure  ratio  of  1.  0.     Based  upon 
these  parameters  and  the  above  estimates  the  number  of  departure  flight  delays 
which  can  occur  may  be  computed  as 

(o.  85)  (60)  (0. 13)  (0.  75)  =  5  per  busy  hour. 

This  represents  335  seconds  (5.6  minutes)  of  flight  delay  per  busy  hour. 

3.4.5  Handoff  to  Ground  Control  Departure  Q 

Due  to  the  nature  of  the  definition  of  this  function  its  potential  im- 
pact would  be  limited  to  the  area  of  manual  activity  for  the  Ramp  Control  po- 
sition. 

In  the  description  of  the  logic  flow  of  this  function  in  paragraph 
3.  2. 3.5  it  was  indicated  that  flights  would  be  entered  into  the  Ground  Control 
Departure  Q  through  a  system  data  entry  by  Ramp  Control  when  no  conflicts 
are  determined  for  the  flight.    If  it  is  estimated  that  this  entry  would  take  ap- 
proximately two  seconds,  this  would  represent  an  increase  of  approximately 
16.5  percent  in  the  manual  activities  of  the  Clearance  Delivery  (Ramp  Control) 
position.      Note,  however,  the  system  could  be  designed  to  automatically  ac- 
complish this  transfer  to  the  Ground  Control  Departure  Q  when  no  conflicts 
are  detected  for  a  flight  and  to  cue  Ramp  Control  to  accomplish  the  frequency 
change  (handover)  instruction. 


3.4.6  Verify  Gate  Assignment 

Due  to  the  nature  of  the  definition  of  this  function  its  impact  would 
be  limited  to  the  area  of  controller  communications  activity.    This  function 
would  eliminate  the  communications  between  flights  and  airlines  flight  opera- 
tions because  the  flights'  destination  gates  would  be  transmitted  to  the  pilots 
by  (inbound)  Ground  Control  as  part  of  the  flights'  taxi  clearance.    However, 
the  communication  of  destination  gate  and  availability  information  was  observed 
for  approximately  60  percent  of  all  arrivals  in  the  analysis  of  controller  com- 
munications.   Since,  for  the  most  part,  these  communications  involved  a  re- 
quest from  Ground  Control  and  a  response  from  the  pilot,  a  reduction  in  com- 
munications activity  would  be  achieved  by  a  one-way  transmission  from  the 
Controller. 

The  net  benefit  is  derived  using  the  results  of  the  (inbound)  Ground 
Control  Communications  analysis,  namely 

•  Gate  assignment  communications  for  60  percent  of  traffic. 

•  Gate  assignment  communications  representing  approximate- 
ly 15  percent  of  all  CTs. 

•  Average  CT  time  of  9.3  seconds. 

It  is  assumed  that  the  one-way  transmission  of  gate  assignment 
would  involve  one  half  of  the  time  for  the  previous  two-way  communications. 
Therefore,  the  net  change  in  gate  assignment  communications  time  could  be 
computed  as 


["+0.40  (4.65)  -  0.60  (4.65)1      0.15    =    -0. 
0.60  (9.3) 


025 


That  is,  a  net  reduction  of  approximately  2.5  percent  of  the  channel  occu- 
pancy of  the  (inbound)  Ground  Control  would  be  accomplished. 


3.4.7  Monitor  Inbound  Ramp  Q 

Within  the  proposed  functional  concept  the  reporting  of  arrival  at 
a  gate  would  be  accomplished  through  a  system  data  entry  by  airlines  flight 
operations. 

This  reporting  is  occasionally  performed,  usually  on  request  from 
Inbound  Ground  Control,  during  low  visibility  conditions  when  flight  operations 
in  the  ramp  area  cannot  be  observed  by  Inbound  Ground.    However,  such  sit- 
uations were  not  explicitly  measured  during  the  O'Hare  Operations  Analysis. 
Therefore,  no  quantitative  assessment  of  this  impact  can  be  derived  here. 

3.4.8  Clear  to  Gate 

The  areas  of  potential  impact  for  this  function  are  listed  below. 

Delays 
None 

Controller  Communications 

Addition  of  a  Ramp  Control  communications  transaction  to  clear 
a  flight  that  has  been  holding  off  the  taxiway  network  in  a  portion 
of  the  ramp  area. 

Manual  Activity 

Addition  of  controller  (Ramp  Control)  flight  status  data  entry — 
Cleared  to  Gate — into  the  system  when  the  flight  is  so  cleared. 

When  a  flight  is  instructed  by  Ground  Control  to  hold  in  the  ramp 
area,  Ground  Control  must  also  transmit  the  instruction  to  taxi  to  its  gate  at 
a  later  time.  Thus,  the  effect  of  this  function  would  be  to  transfer  this  com- 
munication from  Ground  Control  to  Ramp  Control. 

With  respect  to  controller  manual  activity  it  is  estimated  that  the 
required  data  entry  would  take  approximately  2  seconds  for  each  occurrence. 

Holding  of  arrival  flights  off  the  end  of  terminal  building  fingers 
is  accomplished  occasionally  at  O'Hare  but  only  for  B-727  and  smaller  aircraft 


because  of  the  limitations  of  the  space  between  the  terminal  fingers  and  the    inner 
taxiway.     However,  no  explicit  measurements  of  such  situations  were  achieved 
during  the  O'Hare  Operations  Analysis.     Therefore,  no  quantitative  estimates  of 
the  impact  of  this  function  can  be  derived  here. 

3.4.9  Outbound- Inbound  Conflict  Management 

The  benefits  of  this  function  would  be  limited  to  reduction  of  de- 
lays for  both  outbound  aircraft  and  inbound  aircraft.    The  specific  effects  an- 
ticipated would  be: 

•  Reduction  of  delays  to  outbound  flights  due  to  blockage 
by  inbound  flights  on  the  taxiways. 

•  Elimination  of  delays  to  inbound  flights  within  the  ramp 
area  due  to  blockage  by  outbound  flights. 

•  Reduction  of  delays,  to  inbound  flights  outside  the  ramp 
area,  i.e.,  holding  on  the  taxiway  network,  due  to  block- 
age by  outbound  flights. 

The  effects  of  this  function  are  assessed  using  the  results  of  the 
O'Hare  Operations  Analysis. 

With  respect  to  outbound  flights,  it  was  estimated  in  paragraph  3.3.3 
that  13  percent  of  outbound  flights  were  delayed  in  the  ramp  area  and  that  25  per- 
cent of  these  delays  were  due  to  inbound  flights.  The  average  outbound  delay  was 
noted  in  paragraph  3.4.4.  to  be  67  seconds. 

With  respect  to  inbound  flights,  delays  within  the  ramp  area  were  ob- 
served to  affect  8.  4  percent  of  the  arrivals  and  to  have  an  average  duration  of  90 
seconds.     The  O'Hare  analysis  indicated  that  approximately  20  percent  of  arrivals 
experienced  delays  on  the  taxiway  network  due  to  ramp  congestion.    The  average 
taxiway  "hold"  delay  was  measured  as  67.5  seconds. 

For  the  purposes  of  this  analysis  the  parameters  employed  in  the  pre- 
vious O'Hare  system  effectiveness  analysis  are  used  here:  120  operations  per  busy 


hour;  85  percent  air  carrier  traffic;  arrival/departure  ratio  of  1.  0.  Based  upon 
these  parameters  and  the  above  estimates  the  number  of  flight  delays  which  can 
occur  may  be  computed  as: 

(0.  85)  (60)      [(0. 13)  (.  25)  +  (0.  084)  +  (0.  20)]     = 

51     [o.  033  +  0.084  =  0.  2ol     =  16.  2  flights  per  busy  hour 

The  delay  time  may  be  computed 

51      [o.  033  (67)  +  0.  084  (90)  +  0.  20  (67.  5)]     = 
1187  seconds  per  busy  hour 

3.4.10  Composite  Benefits 

The  results  of  the  preceding  analyses  may  be  combined  to  provide 
an  estimate  of  the  total  (net)  benefits  of  the  proposed  Ramp  Control  System. 
These  results  indicate: 

•  A  reduction  of  approximately  16  percent  of  the  communication 
channel  occupancy  (workload)  of  the  Clearance  Delivery 
(Ramp  Control)  position. 

•  A  reduction  of  approximately  2.5  percent  of  the  communica- 
tion channel  occupancy  (workload)  of  the  Inbound  Ground  Con- 
trol position. 

•  A  reduction  of  approximately  27  percent  of  the  manual  ac- 
tivities workload  of  the  Flight  Data  position  . 

•  An  increase  of  approximately  7  percent  of  the  manual  ac- 
tivities workload  of  the  Clearance  Delivery  (Ramp  Control) 
position. 

•  A  reduction  of  approximately  16  percent  of  the  manual  activi- 
ties workload  of  the  Outbound  Ground  Control  position. 

While  there  is  a  net  increase  in  the  manual  activity  workload  of  the 
Clearance  Delivery  (Ramp  Control)  position,  this  does  not  seriously  detract 
from  the  overall  benefits  of  the  system  concept.    During  the  O'Hare  Operations 
Analysis  the  manual  activity  workload  of  this  position  was  determined  to 


account  for  16.  9  percent  of  the  controller's  time  during  a  busy  hour.    In  addition, 
it  was  noted  that  these  activities  occurred,  for  the  most  part,  simultaneously 
with  his  communications  activities.    This  situation  is  expected  to  continue  in 
the  proposed  Ramp  Control  System.    Therefore,  the  reduction  of  approximate- 
ly 16  percent  of  the  controller's  communications  activity  more  than  than  com- 
pensates for  this  increase  in  manual  activity. 

The  estimated  aircraft  delays  represent  an  extremely  important  factor. 
The  total  estimated  delay  for  all  flights  is  1522  seconds  (25.4  minutes)  per  busy 
hour.    Using  the  weighted  average  cost  of  $11.  23  per  aircraft  operating  minute  de- 
rived in  the  O'Hare  system  effectiveness  analysis,  this  delay  represents  costs  of: 

•  $285  per  busy  hour 

•  $4564  per  day 

•  $1,665,860  per  year 

Estimates  of  actual  savings  due  to  the  proposed  RCS  have  not  been  made; 
however,  the  above  figures  demonstrate  the  substantial  costs  incurred  by  the  air- 
line operators  which  could  be  reduced  through  application  of  positive  Ramp  Control 
concepts. 


SECTION  4  -  DEVELOPMENT  OF  A  GROUND  CONTROL 
SYSTEM  (GCS)  CONCEPT 


4.  1  INTRODUCTION 

Control  of  aircraft  on  the  surface  of  an  airport  is  a  substantially  differ- 
ent control  process  from  that  performed  at  other  ATC  control  positions.     In  gen- 
eral the  route  structure  of  the  airport  is  more  complex  than  that  in  the  airspace; 
the  number  of  aircraft  sources  (ramps,   for  example)  are  larger  and  the  inter- 
actions between  surface  traffic  movement  and  the  interacting  local  and  ramp  areas 
more  complex.     Pilot  options  are  more  diverse  since  the  aircraft  can  hold  at  al- 
most any  location  and  the  navigational  aspects,  relying  heavily  on  VGE  equipment, 
are  appreciably  different  from  those  followed  by  the  pilot  when  airborne. 

The  concentration  of  traffic  in  the  vicinity  of  a  major  terminal  is  sig- 
nificantly higher  than  that  existing  at  other  control  positions.     The  relatively  slow 
speeds  used  by  aircraft  in  taxiing,  the  unique  aspects  of  aircraft  turning  (either 
at  intersections  or  at  runway  turnoffs),   and  the  pavement  constraints  of  most  air- 
ports,  coupled  with  the  recent  advent  of  heavies,   are  some  of  the  factors  that 
make  the  ground  controller's  job  indeed  a  difficult  one  even  in  conditions  of  excel- 
lent visibility.    The  experience  of  the  pilots  is  believed  to  be  a  major  factor  in  the 
"workability"  of  the  existing  GCS.     Aircraft  taxiing  on  "highways"  such  as  the 
Outer  Circular  or  some  of  the  parallels  at  O'Hare  maintain  headway  with  respect 
to  each  other.     This  type  of  conflict,   therefore,   is  not  something  that  a  controller 
must  be  concerned  with  since  he  knows  that  the  pilots  will  exercise  this  function. 
At  intersections,  however,  no  such  "rules  of  the  road"  exist  because  of  the  single 
lane  nature  of  the  existing  pavements.     Scheduling  of  the  pavement  facilities,  which 
must  serve  a  wide  variety  of  runway  configurations,   is  by  no  means  a  simple  task. 
An  idea  of  the  complexity  of  the  control  functions  may  be  obtained  from  the  discus- 
sion of  the  individual  functions  set  forth  under  the  performance  requirement  sec- 
tion.    The  manner  in  which  these  interact  with  each  other  will  be  shown  on  a 


composite  operational  logic  figure.  The  required  amount  of  functional  activity  in 
the  present  manual  system  is  compared  in  the  benefits  analysis  section  with  those 
anticipated  in  a  semiautomated  GCS. 

4.  2  REQUIREMENTS  ESTIMATION 

4.  2.  1  General 

The  area  of  responsibility  of  the  Ground  Control  System  includes  all 
taxiway  links  and  intersections  exclusive,  however,   of  ramp,   cargo,  and  hangar 
areas.     This  system  must  interface  with  other  pavement  areas  (facilities)  which 
are  under  the  control  of  other  systems.     These  interface  areas  include  the  ramp 
entry /exit  areas,   runway  turnoff  links,  departure  Q  nodes  serviced  by  Local  Con- 
trol, and  the  cargo  and  hangar  areas  from  which  aircraft  may  also  wish  to  enter 
the  GCS.    Runway  crossings  represent  a  facility  managed  on  a  time-shared  basis 
by  both  the  Local  Control  system  as  well  as  the  Ground  Control  System.     During 
some  active  runway  configurations,   inactive  runways  may  be  used  (4L/22R  at 
O'Hare  for  example)  for  taxi  purposes.     These  will  be  considered  as  part  of  the 
taxi  system  for  the  particular  runway  configuration  in  use.     The  above  description, 
supplemented  by  the  taxi  network  analysis  of  Appendix  A,  defines  the  required 
coverage  area  of  the  Ground  Control  System.   Special  mention  should  be  made  of 
staging  areas  (such  as  the  Penalty  Box  at  O'Hare)  which  are  portions  of  the  taxi- 
way  network  wherein  an  aircraft  is  delayed  because  of  the  unavailability  of  a 
facility  (i.  e. ,  a  gate  for  example)  outside  of  the  ground  controller's  area  of  re- 
sponsibility.   Non-paved  areas,   service  roads,   fuel  depots,  and  all  areas  closed 
to  aircraft  traffic  are  excluded  from  the  coverage  area  of  the  GCS. 

4.  2.  2  Functional  Requirements  and  Operational  Logic 

The  major  functions  to  be  performed  by  the  GCS  have  been  derived 
from  a  detailed  study  of  existing  control  procedures  and  examination  of  aircraft 
scenarios  and  maneuvers  during  their  use  of  the  various  ground  control  facilities. 
It  is  expected  that  some  of  these  functions  can  be  improved  materially  by  use  of 


semi-automated  control  techniques;  other  functions,   however,   will  still  be  per- 
formed in  a  manner  similar  to  the  present-day  system. 

The  control  functions  may  be  divided  into  three  categories,   based  upon 
whether  they  are  required  for  Departures,   Arrivals,   or  both. 

These  Control  Functions  are  as  follows: 

Departures 

A.  Release  of  Departure  A/C  (from  Ramp  Areas)  (including  monitor- 
ing status  of  Ground  Control  Departure  Q) 

B.  Handoff  to  Local  Control  Departure  Q. 
Arrivals 

C.  Formation  and  Monitoring  of  Ground  Control  Arrival  Q 

D.  Acceptance  of  Arrival  A/C  (into  Taxi  System) 

E.  Penalty  Box/Staging  Area  Management 

F.  Interface/Handoff  to  Ramp  Control 
Common 

G.  Routing  Control  (Selection  and  Verification) 

H.     GCS  Conflict  Management 

Each  of  these  functions  is  examined  in  order  to  determine  the  informa- 
tion needed  by  the  data  processing  subsystem  (or  controller)  to  perform  the  appro- 
priate job  (or  task).     There  is  a  substantial  amount  of  interaction  between  many  of 
these  Control  Functions;  for  example,   Function  A  requires  (1)  that  Function  H  (no 
Ramp  Exit  Conflict  exists)  is  satisfied;  (2)  that  Function  G  (Routing  Control)  has 
been  performed.     In  the  present  system  the  logic  used  is  that  if  Function  H  is  not 
satisfied  (i.  e. ,  a  Ramp  Exit  Conflict  exists)  then  no  contact  is  made  by  the 
Ground  Controller  with  the  Departure  A/C. 


Table  4-1  lists  the  major  Control  Functions  required  in  the  Ground 
Control  System.     This  table  also  indicates  where  interface  is  required  with  the 
associated  Local  Control  or  Ramp  Control  systems.    The  next  heading  of  this 
table  lists  (in  order)  the  sequence  of  events  or  interacting  functions  which  are  to 
be  recognized  or  performed  during  the  designated  function.    These  entries  may  be 
used  to  identify  the  demand  (or  request)  for  service;  the  actual  initiation  of  service 
and  the  completion  of  service  for  each  function  of  the  aircraft  control  process  are 
parts  of  a  series  of  tandem  queues  managed  by  the  controllers. 

While  some  "Demand"  events  may  be  defined  solely  in  terms  of  air- 
craft location  (and  possibly  other  physical  parameters),  other  "Demand"  events 
must  be  specified  by  the  users  (i.  e. ,   a  pilot  indicating  he  is  ready  to  taxi).     On 
the  other  hand,  the  events  identifying  Start  and  End  of  Service  (or  activity)  are 
essentially  recognizable  from  surveillance  information,  i.  e.  ,  an  aircraft  has  left 
the  Ramp  Area,   is  about  to  turn  off  the  runway  after  landing,   or  is  "near"  the 
Local  Control  Departure  Q.     It  is  these  events  which  must  be  examined  for  each 
function  in  order  to  determine  the  performance  requirements  of  the  surveillance 
sensor(s). 

The  next  column  on  Table  4-1  provides  an  estimate  of  the  information 
(or  data  requirements)  needed  by  the  controller  or  data  processing  system.    The 
various  types  of  data  requirements  (Link  Occupancy,   Movement  Detection,  etc. ) 
are  discussed  in  the  Appendices  wherein  estimates  of  the  performance  require- 
ments of  the  sensors  are  given  (and  included  in  Table  4-1).     Changes  in  these  data 
requirements  are  expected  as  refinements  are  made  in  the  development  of  the 
GCS  concept. 

The  interaction  between  these  Control  Functions  is  described  by  an 
Operational  Logic  diagram  as  shown  in  Figure  4-1.    Aircraft  wishing  to  enter  the 
taxi  system  are  designated  as  being  in  the  Ground  Control  Departure  Q  or  the 
Ground  Control  Arrival  Q.     Upon  entry,  these  aircraft  "move"  into  an  "Active" 
A/C  status,  i.  e.  ,   service  is  being  provided  by  the  taxiway  facilities.     Termination 
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(or  suspension)  of  service  to  "Active"  aircraft  will  occur  when  they  are  "handed 
off"  to  the  Local  Control  Departure  Q,  the  Penalty  Box,  or  the  Ramp  Control  Sys- 
tem.   All  "Active"  aircraft  are  "continually"  examined  for  conflict  recognition 
purposes.     Where  necessary  (as  determined  by  the  Controller)  certain  aircraft 
may  be  "Held"  in  order  to  resolve  a  potential  conflict.     These  A/C  (in  the  "Held" 
A/C  List)  are  reactivated  by  the  Controller  at  some  later  time.     In  Figure  4-1 
GCS  activated  "flags"  to  the  Controller  are  indicated  wherever  controller  inter- 
vention is  required,  i.e., 

Clear  departure  A/C  into  taxiway  system 

Cleared  departure  A/C  has  not  entered  taxiway  system 

Provide  route  to  cleared  aircraft 

A/C  is  "lost",   i.  e.  ,   not  following  route 

Conflict  resolution,   i.  e.  ,    "Hold"  A/C,  etc. 

Clear  "Held"  A/C  to  move 

R/W  crossing  clearance 

Acceptance  of  arrival  aircraft 

Resolution  of  turn-off  generalized  conflicts 

Ramp  entrance  conflicts 

Penalty  box  routing 

Time  for  Handoff 

Five  types  of  conflict  have  been  identified  for  GCS  Conflict  Manage- 
ment (Function  H).     These  are: 

H-l  Ramp  Exit  Conflicts 

H-2  R/W  Crossing  Conflicts 

H-3  Taxiway/Taxiway  Conflicts 

H-4  Turn-off  Generated  Conflicts 

H-5  Ramp  Entrance  Conflicts 

With  the  exception  of  taxiway /taxiway  conflicts,   all  others  are  deter- 
ministic in  nature,   i.  e. ,  they  must  only  be  evaluated  at  or  near  the  time  of 
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demand.     The  turn-off- generated  conflict  is  defined  as  that  caused  to  aircraft  in 
the  vicinity  of  landing  aircraft  turning  off  the  runway  (and  having  priority) . 

4.  2.  3  Performance  Requirements 

4.  2.  3. 1        General 

Each  of  the  eight  control  functions  to  be  performed  by  the  GCS  repre- 
sents an  activity  involving  the  interaction  of  a  data  acquisition  system,   a  data 
processing  system,   and  data  inputs  to  and  from  the  controller  with  the  controller 
directing  aircraft  movement  by  voice  via  a  standard  radio  link. 

Most  of  the  Control  Functions  involve  the  provision  of  advisory  notices 
(Flags)  to  the  controller  and  controller-to-machine  indication  of  action  taken. 
However,  a  need  for  function  verification  has  been  identified,   i.  e.  ,  an  aircraft  is 
indeed  following  instructions  as  given  by  controller.     This  verification  can  be  per- 
formed as  at  present,   i.  e.  ,  visual  verification  by  controller  or  by  machine  proc- 
ess, viz  A/C  does  not  move  with  "T"  seconds,  A/C  moves  after  "Hold"  instruc- 
tion, etc. 

The  performance  requirements  of  all  eight  control  functions  are  dis- 
cussed with  technical  analyses  of  certain  aspects  of  requirements  provided  in  the 
Appendices.     These  aspects  are  estimates  of  required  accuracies  for  the  DAS 
sensors,  the  minimum  GCS  response  time  for  recognition  of  conflicts,  etc. 

The  GCS  response  time  represents  the  interval  between  the  time  an 
event  actually  happens  and  the  time  it  can  be  recognized  by  the  controller.    This 
will  vary  with  the  particular  type  of  indication  used,   i.  e. ,   it  is  expected  to  be  dif- 
ferent for  Movement  Detection  as  contrasted  with  Link  Occupancy.     Transition  of 
an  A/C  from  a  "stopped"  condition  to  a  "moving"  condition  may  be  easily  recog- 
nized almost  immediately  under  visual  conditions.     Using  surveillance  sensors, 
algorithms  must  be  established  to  define  "movement";  the  approach  taken  has  been 
that  an  aircraft  moving  at  less  than  a  specified  threshold  speed  is  considered  as 
"stopped".    The  GCS  response  time  for  this  component  would  then  be  defined  as 


from  the  time  the  aircraft  speed  actually  dropped  below  this  threshold  value  to  the 
time  this  data  element  was  available  to  the  controller.     In  general,   GCS  response 
times  of  from  2  seconds  to  3  seconds  have  been  specified  since  overall  system  re- 
sponse time  considerations  indicate  prediction  intervals  of  from  15  seconds  to  30 
seconds  are  of  most  significance  in  the  control  process.    Where  non-critical  func- 
tions are  involved,  the  GCS  response  time  may  be  relaxed  to  4  seconds  to  7  sec- 
onds.    Tradeoffs  can  be  made  between  GCS  response  time  and  sensor  performance 
requirements;  these  should  be  considered  in  the  examination  of  specific  sensor  and 
display  approaches. 

4.  2.  3.  2        Release  of  Departure  Aircraft  (Function  A) 

This  function  includes  monitoring  the  status  of  the  Ground  Control  De- 
parture Q,   i.  e. ,  those  aircraft  "demanding"  entry  from  the  ramp  area  into  the 
taxi  system,  as  well  as  the  processes  actually  involved  in  release  of  A/C  into  the 
taxi  system. 

Acquisition  by  the  sensor  system  may  be  desirable  for  those  aircraft 
at  the  "head"  of  each  sub-queue  although  this  may  pose  special  resolution  problems. 
An  alternate  method  would  rely  on  acquisition  after  the  aircraft  starts  to  move  out 
onto  its  first  link. 

Interface  with  the  Ramp  Control  System  is  necessary  to  establish  A/C 
ID,  ramp  areas,   and  time  of  entry  into  the  GC  Departure  Q.     Monitoring  of  the 
GC  Departure  Q  is  essentially  a  "housekeeping"  function  which  can  readily  be  per- 
formed by  a  computer  in  a  manner  that  should  simplify  the  current  handling  and 
monitoring  of  flight  strips  by  the  Outbound  Ground  Controller  and  Clearance  De- 
livery position. 

Release  of  a  Departure  A/C  from  the  Ground  Control  Departure  Q  into 
the  taxiway  system  is  a  function  interacting  with  several  other  functions,  namely 
G  and  H.     Function  G  (Routing  Control)  requires  the  controller  to  assign  a  depar- 
ture R/W  as  well  as  a  taxi  route  to  the  departing  aircraft.    The  performance  of 


this  function  is  not  very  time  sensitive,   i.  e. ,   it  could  be  performed  before  (one 
minute  to  two  minutes  perhaps)  the  actual  release  of  the  aircraft.     On  the  other 
hand,  performance  of  Function  H  (GCS  Conflict  Management)  must  be  done  in  real 
time  with  a  minimum  of  delay.     Accomplishment  of  this  "merging"  of  aircraft  with 
nearby  traffic  will  be  examined  under  Function  H;  this  type  of  conflict  will  be  de- 
fined as  a  "Ramp  Exit  Conflict".    Successful  completion  of  Functions  G  and  H  per- 
mits the  controller  to  release  the  aircraft  into  the  system.     It  is  now  the  "job"  of 
the  sensor  data  processing  equipments  to  recognize  (i.  e.  ,   begin  track)  entry  of 
this  particular  aircraft  into  the  taxi  system.    A  logic  flow  diagram  representing 
activities  to  be  performed  during  this  function  is  shown  in  Figure  4-2. 

Recognition  of  A/C  entry  onto  the  taxiway  could  be  accomplished  in  a 
variety  of  ways.    These  include: 

•  A  "passage"  detector  at  the  ramp  exit 

•  Movement  detection  on  the  designated  R/l  link 

•  Position  detection  on  the  R/l  link  (Link  Occupancy) 

•  Combination  of  some  of  the  above 

As  shown  in  the  Appendices,  the  R/l  links  are  short  at  O'Hare  and  air- 
craft exit  speeds  are  expected  to  range  from  5  knots  to  10  knots.  The  time  avail- 
able for  acquisition  and  recognition  of  entry  does  not  appear  critical;  a  response 
time  of  4  seconds  to  7  seconds  for  an  individual  Departure  should  be  acceptable  for 
verification  of  entry.  It  should  be  noted,  however,  that  in  many  cases  aircraft  are 
released  from  a  ramp  area  in  "batches"  and  that  this  factor  will  play  a  role  in  the 
update  interval. 

After  permission  to  taxi  has  been  given,  the  sensor  system  must  verify 
entrance  of  the  aircraft  into  the  taxi  system.  After  initial  acquisition  of  the  target, 
position  information  of  sufficient  accuracy  should  be  available  to  recognize  that  the 
aircraft  has  indeed  moved  out  onto  the  designated  R/l  Link.  If  an  aircraft  standing 
clear  of  the  R/l  link  accelerates  at  0.  lg  to  7.  5  knots  (estimated  ramp  taxi  speed) 
and  then  maintains  that  velocity,  it  will  cover  38.3  feet  in  five  seconds.    If  a  link 
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occupied  test  is  defined  as  measured  position  (xg)  >  19.  2  feet  and  the  position 
error  is  normal  with  zero  mean  and  standard  deviation  of  9. 6  feet,  then  an  air- 
craft at  38.3  feet  (i.e. ,  five  seconds  into  the  link)  will  indicate  link  occupancy  with 
97.5  percent  certainty  and  an  aircraft  clear  of  the  link  will  indicate  link  occupancy 
(i.  e.  ,  false  alarm)  only  2.  5  percent  of  the  time.    With  a  modest  sample  rate  (e.g. , 
two  seconds)  worst  case  detection  time  is  seven  seconds  satisfying  the  4-7  second 
specified.    If  position  is  sensed  every  0. 1  seconds  and  measured  position  is  com- 
puted each  25  samples  with  a  first  order  filter  (see  Appendix  D)  then  the  single 
sensed  position  accuracy  requirement  can  be  relaxed  to  25  feet  (9.  6/.  38)  and  the 
worst  case  detection  time  is  7. 5  seconds. 

If  Movement  Detection  of  this  aircraft  (rather  than  Link  Occupancy)  is 
used,  similar  position  accuracy  and  detection  time  as  above  is  required  (see 
Appendix  D). 

4.  2. 3.  3        Handoff  to  Local  Control  Departure  Q  (Function  B) 

Under  present  procedures  the  Outbound  Ground  Controller  will  "hand- 
off"  a  Departure  aircraft  after  it  has  passed  the  last  node  before  the  Local  Control 
Departure  Q  area.    Since  these  links  are  relatively  long  for  most  Department  Q 
areas,  the  "handoff"  time  is  not  critical.    It  should  of  course  take  place  sufficiently 
before  the  Departure  Q  area    so  that  Departures  can  be  handled  expeditiously  by 
Local  Control  if  no  Departure  Q  exists.    This  method  of  operation  is  based  upon 
the  premise  that  no  further  taxiing  conflicts  can  arise. 

For  the  South  runways  at  O'Hare  these  "last"  links  are  as  follows: 


Approx. 

Runway 

Final  Link 

Link  Length 

4R 

S16/Y18 

>  1000' 

9R 

S14/Y12 

>  1000' 

14R 

SI  or  S2/Y1 

900/>1000' 

22L  or  27L 

S11/Y17 

>  1000' 

32L 

S15/Y12 

900' 

Similar  lengths  exist  on  the  North  side  except  for  9L  where  the  "last" 
link  is  about  500  ft  long  after  the  intersection  of  the  New  Scenic  and  the  9L/27R 
parallel.    Using  a  minimal  estimated  taxi  speed  of  12.  5  knots,  an  aircraft  will 
have  moved  onto  the  last  link  by  150  feet  in  seven  seconds.    With  position  detection 
rationale  as  in  paragraph  4. 2.3.2  a  standard  deviation  on  measured  position  of 
37. 5  feet  would  provide  97.  5  percent  probability  of  detection,  2.  5  percent  proba- 
bility of  false  alarm,  and  a  worst  case  detection  time  of  7  +  T0.    A  7-10  second 

b 

detection  time  requirement  could  be  met  with  modest  data  rates  (e.g. ,  T    =  2 
seconds). 

4.  2.  3.  4        Formation  and  Monitoring  of  Ground  Control  Arrival  Q  (Function  C) 

The  Inbound  Ground  Controller  has  responsibility  at  O'Hare  for  two 
categories  of  aircraft.    One  category  consists  of  aircraft  at  hangar  areas  wishing 
to  taxi  to  the  ramp  areas  or  those  in  the  Penalty  Box  and  are  now  ready  to  leave. 
The  other  category  is  landing  aircraft  which  are  handed  off  to  the  Inbound  Ground 
Controller  from  either  one  of  the  two  Local  Control  positions.     It  is  this  latter 
category  which  must  be  handled  rapidly.    Operational  factors  involved  in  the  "hand- 
off"  process  from  Local  Control  which  must  be  considered  include: 

1.  Selection  of  a  particular  R/W  turnoff  is  the  pilot's  responsibility, 
not  the  controller's. 

2.  In  the  present  system  it  appears  that  the  Local  Controller  will  per- 
form the  handoff  on  an  anticipatory  basis,   i.  e. ,  while  the  plane  is 
still  partially  on  the  runway  or  near  a  turnoff  which  the  Local  Con- 
troller believes  will  be  used  by  the  pilot.     While  this  approach  is 
desirable  for  minimizing  "handoff"  delays,   it  could  possibly  result 
in  runway  conflicts. 

3 .  Communications  between  pilot/ground  controller  must  be  confirmed 
at  handoff.  A  position  report  is  usually  given  by  the  pilot  at  this  time. 

4.  A  "landing"  aircraft  takes  from  30  seconds  to  40  seconds  from 
runway  threshold  to  turnoff.     During  most  of  this  period  this 
particular  aircraft  must  be  considered  as  demanding  "service"  at 
all  R/W  turnoff s  (except  of  course  those  already  passed).     Meas- 
urement of  aircraft  position  and  velocity  data  for  prediction  pur- 
poses during  R/W  deceleration  can  permit  reduction  in  the  number 
of  potential  "turnoffs"  that  could  actually  be  used  by  the  landing 
aircraft. 


5.  Potential  conflicts  between  aircraft  entering  turnoffs  are  most 
likely  to  occur  with  the  preceding  landing  aircraft  which  is  taxi- 
ing down  the  associated  parallel  taxiway    (turnoff-generated  con- 
flicts). 

6.  Both  "high  speed"  and  "low  speed"  R/W  turnoffs  must  be  consid- 
ered.    The  former  intersects  the  runway  with  turnoff  angles  as 
low  as  30  degrees  while  the  latter  have  intersecting  angles  near 
90  degrees.    This  factor  can  be  significant  in  detecting  "Turn 
Recognition"  as  a  means  of  formation  of  the  Ground  Control  Arrival 
Q  for  landing  aircraft.    Aircraft  velocity  at  turnoff  is  expected  to 
vary  somewhat  for  these  two  cases. 

7.  The  responsibility  for  runway  status  monitoring,  or  recognition 
that  the  runway  is  clear  or  occupied,  belongs  to  the  Local  Con- 
troller. 

8.  For  some  runways  (primarily  on  the  North  side  of  O'Hare)  the 
Local  Control  does  not  "handoff"  the  aircraft  to  Inbound  Ground 
Control  at  or  near  the  R/W  turnoff  point.     He  will  actually  perform 
taxi  control  until  the  landing  aircraft  has  been  brought  across  other 
active  runways. 

To  perform  Function  C  it  is  recommended  that  "Arrival"  aircraft  from 
hangars  be  handled  as  "popups"  and  entered  into  the  Ground  Control  Arrival  Q  on  a 
manual  basis  since  in  many  cases  beacon  codes  must  be  assigned  and  temporary 
(not  flight  numbers)  aircraft  IDs  are  employed.    Aircraft  reentering  the  taxi  sys- 
tem from  the  Penalty  Box  are  simply  reacquired  as  they  leave  the  staging  area. 
Entry  of  landing  aircraft,  on  the  other  hand,  into  the  Ground  Control  Arrival  Q 
may  be  performed  manually  (as  at  present)  or  automatically.     In  the  automatic 
case  a  sensor  system  would  recognize  perhaps  an  aircraft  turning  at  a  particular 
R/W  turnoff  (Turnoff    Recognition)  or  occupancy  of  the  turnoff  link  (Link  Occupancy). 

A  logic  flow  chart  for  this  function  and  the  succeeding  one  (Function  D  - 
Acceptance  of  Arrival  A/C)  is  shown  in  Figure  4-3;  this  also  depicts  the  interfac- 
ing functions  of  Routing  Control  and  GCS  Conflict  Management.     The  results  of  the 
Operations  Analysis  effort  at  O'Hare  showed  that  in  almost  no  cases  (8  out  of  over 
700  arrivals)  is  an  aircraft  "held"  at  the  turnoff  link.     It  is  believed  that  this  policy 
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Logic  Flow  Diagram  for  Entry  of  Arrival 
Aircraft  (Functions  C  and  D) 


is  followed  in  order  to  expedite  the  aircraft  off  the  runways.     The  Inbound  Ground 
Controller,   therefore,   if  a  conflict  does  exist  with  an  aircraft  taxiing;  on  the  asso- 
ciated parallel,  must  issue  a  "Hold"  instruction  to  this  aircraft  in  order  to  clear 
the  landing  aircraft  into  the  taxi  system  at  turnoff  as  soon  as  possible.     It  is  there- 
fore highly  desirable  to  recognize  entry  into  the  Ground  Control  Arrival  Q  (GCAQ) 
as  soon  as  possible.    Turnoff  Recognition  or  Turnoff  Prediction,  therefore,   ap- 
pears more  desirable  as  a  recognition  of  this  event  than  does  occupancy  of  the  turn- 
off  link. 

After  the  Inbound  Ground  Controller  has  issued  taxi  clearance  (and 
routing)  to  the  landing  aircraft,  the  sensor  system  should  confirm  (as  was  done 
for  ramp  area  departures)  actual  entry  into  the  taxi  system;  i.  e.  ,  the  aircraft 
becomes  an  "Active"  user  of  the  taxi  network. 

If  Turnoff  Prediction  is  used  as  a  method  for  early  recognition  of 
"demand"  for  taxiway  service  by  landing  aircraft,  the  estimation  techniques  of 
Appendix  E  may  be  used  to  obtain  required  position  and  velocity  accuracy  of  sen- 
sor data  when  the  aircraft  is  braking  on  the  runway.     Using  pre-turnoff  speeds  of 
30  knots  to  60  knots  (50-100  fps)  the  error  in  Turnoff  estimate  due  to  Position  error 


while  that  due  to  the  velocity  error  is 

a 

where  t  is  the  prediction  time  interval.    If  otj  and  at2  are  taken  as  2  seconds,  then 
a    =  50  (2)  =  100  ft  for  V  =  30  knots  and  a  V/V  =  2/15  =  0.  13  or  a     =  0.  13  (50) 
=  6.5  fps.    These  values  represent  performance  requirements  imposed  on  the 
Local  Control  System  because  of  its  interaction  with  the  Ground  Control  System 
and  are  not  shown  on  Table  4-1. 


4.  2.  3.  5         Acceptance  of  Arrival  Aircraft  (Function  D) 

As  described  in  the  previous  section  landing  aircraft  must  be  imme- 
diately accepted  into  the  taxi  system.     The  sensor  system  to  verify  entry  may  be 
used  to  recognize  aircraft  heading  change  (Turn  Recognition)  near  the  turnoff  point. 
Alternately,  position  data  may  be  used  to  determine  link  occupancy  on  the  Runway/ 
Taxiway  Turnoff  Link.     The  former  technique  may  offer  certain  advantages  in  a 
position  measurement  system  having  unequal  errors  in  the  two  coordinates  although 
higher  sampling  rates  may  be  required.    The  Turnoff  links  are  longer  than  the  R/I 
links  and  higher  taxi  speeds  will  be  used.    If  Link  Occupancy  is  used  as  the  verifi- 
cation criteria  and  the  exit  velocity  is  estimated  at  30  knots  then  using  position  de- 
tection rationale  as  in  paragraph  4.2.3.2  a  standard  deviation  on  measured  posi- 
tion of  25  feet  will  provide  97.  5  percent  probability  of  detection,  2.  5  percent  proba- 
bility of  false  alarm,  and  a  detection  time  of  2-3  seconds  with  modest  data  rates 
(e.g. ,  T    =  2  seconds).    It  is  estimated  that  the  GCS  response  time  for  this  function 
should  be  two  seconds  to  three  seconds. 

4. 2. 3.  6        Penalty  Box/Staging  Area  Management  (Function  E) 

Arrival  aircraft  which  must  be  "held"  in  the  Penalty  Box  or  other  stag- 
ing areas  because  of  gate  unavailability  or  related  reasons  are  handled  somewhat 
differently  by  the  Inbound  Ground  Controller  than  aircraft  which  are  "held"  because 
of  conflicts.     In  the  latter  case  the  controller  and/or  the  Ground  Control  system 
will  be  able  to  determine  the  end  of  a  conflict  and  therefore  the  need  to  change  the 
aircraft  from  a  "Hold"  condition  to  an  "Active"  or  moving  status.    The  time  at 
which  an  aircraft  is  ready  to  leave  the  Penalty  Box  or  staging  area  must  be  fur- 
nished to  the  controller  either  via  communications  with  the  pilot  or  possibly  via 
the  Ramp  Control  system. 

The  Penalty  Box  at  O'Hare  is  approximately  500  feet  long  and  there- 
fore can  be  used  as  a  staging  area  for  perhaps  two  to  four  aircraft  depending  on 
equipment  type.  It  has  two  entrance/exit  nodes  and  is  located  fairly  close  to  the 
ramp  areas. 


The  staging  areas  may  be  considered  as  the  initial  destination  of  those 
landing  aircraft  which  do  not  have  a  gate  and  the  designated  (by  the  controller)  taxi 
route  is  given  on  this  basis.     Recognition  of  aircraft  entry  into  the  Penalty  Box  by 
the  sensor/data  processing  system  essentially  completes  the  initial  handling  of  this 
aircraft;  at  this  time  the  aircraft  may  be  considered  as  moving  into  a  non-active 
status,   i.  e. ,   into  the  Penalty  Box  Q. 

Demand  by  the  pilot  for  release  from  the  Penalty  Box  necessitates  that 
the  Inbound  Ground  Controller  (and  Ground  Control  system)  perform  a  release  func- 
tion similar  to  that  of  Function  A,   i.  e.  ,   both  Conflict  Management  and  Routing  Con- 
trol will  be  involved.     If  these  are  satisfied,  permission  to  depart  from  the  Penalty 
Box  can  be  given  via  the  voice  link.     It  may  be  desirable,   because  of  the  relatively 
short  distance  between  the  Penalty  Box  and  the  ramp  area,  to  interpose  one  addi- 
tional step  before  permission  to  taxi  is  given.     This  step  would  be  a  check  of  the 
status  of  the  particular  ramp  area  to  determine  that  it  is  not  blocked  by  several 
departure  aircraft. 

Recognition  of  aircraft  departure  from  the  Penalty  Box  must  next  be 
performed  by  the  sensor/data  processing  system  in  order  to  verify  that  the  con- 
trol function  has  been  complied  with.  Control  of  aircraft  within  the  Penalty  Box 
area  is  not  currently  envisioned  as  a  semi-automated  function. 

For  those  delayed  aircraft  which  are  placed  in  staging  areas  other 
than  the  Penalty  Box  (such  as  the  cargo  taxiway  for  certain  runway  configurations) 
recognition  of  the  entry  to  and  exit  from  this  condition  can  be  most  readily  per- 
formed by  movement  detection  (start/stop)  in  the  designated  "Hold"  area.     Appli- 
cation of  this  method  within  the  Penalty  Box  may  impose  more  stringent  resolution 
requirements  on  the  sensor  system  than  at  most  other  points  in  the  taxi  network. 
Link  (or  node)  occupancy  at  the  two  Penalty  Box  transitions  possibly  supplemented 
by  route  history  data  or  movement  detection  should  be  sufficient  to  support  the 
Penalty  Box  Management  function. 


The  exit/entrance  dimensions  near  the  Penalty  Box  as  well  as  antici- 
pated aircraft  speeds  are  expected  to  be  similar  to  those  of  the  Ramp  Exit  Function 
A.    Entrance  verification  response  times  of  7-10  seconds  to  temporarily  end  ser- 
vice should  be  adequate.    In  seven  seconds  an  aircraft  moving  at  a  typical  ramp 
speed  of  7.  5  knots  will  travel  90  feet  into  the  penalty  box.    With  position  detection 
rationale  as  in  paragraph  4. 2. 3.  2  a  standard  deviation  of  25  feet  would  provide 
97.  5  percent  probability  of  detection,  2.  5  percent  probability  of  false  alarm  and  a 
detection  time  of  7-10  seconds  with  modest  data  rates  (e.g. ,  T    =  2  seconds). 
Exit  verification  response  times  and  accuracy  requirements  are  similar  to  those 
of  verifying  entry  into  the  taxi  ways  from  the  ramps  (Function  A). 

Figure  4-4  illustrates  the  operational  logic  for  this  function. 

4.  2.  3.  7        Interface/Handoff  to  Ramp  Control  (Function  F) 

Arrival  aircraft  entering  the  ramp  area  at  O'Hare  currently  do  not 
"sign  off"  the  Inbound  Ground  Control  channel;  it  appears  that  the  entrance  event 
is  visually  recognized  by  the  controller  and  the  aircraft  is  crossed  out  on  the 
scratch  pad  he  uses  to  keep  track  of  "Inbounds".    Arrival  aircraft,   in  many  cases, 
cannot  enter  most  ramp  areas  if  a  "Departure"  is  in  "pushback".     This  type  of 
scheduling  conflict  is  one  of  the  most  prevalent  at  O'Hare  and  explains  why  so  many 
of  the  "Holds"  occur  in  the  vicinity  of  the  Inner  and  Outer  Circulars.    While  under 
the  present  day  system  the  Tower  Controllers  do  not  have  responsibility  for  the 
ramp  area,  it  can  readily  be  seen  that  they  cannot  perform  their  function  of  taxi- 
way  management  unless  they  are  cognizant  of  the  status  of  the  various  ramp  areas, 
i.  e. ,  their  availability  for  a  particular  arrival. 

A  preliminary  logic  diagram  for  this  function  is  shown  in  Figure  4-5 
wherein  "Arrival"  aircraft  within  "X"  feet  (or  a  certain  time  -  perhaps  20  seconds 
to  30  seconds)  of  ramp  entrance  may  be  considered  as  requesting  usage  of  the  par- 
ticular ramp.    This  information  probably  should  be  supplied  to  the  Ramp  Control 
system  for  scheduling  control  of  "pushbacks"  and  other  "Arrivals".     Initial  check 
of  ramp  area  availability  may  be  made  by  checking  the  status  of  the  Ground  Control 
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Departure  Q.    However,  this  is  not  sufficient  to  establish  ramp  area  availability 
and  it  is  envisioned  that  the  Ramp  Control  system  should  have  the  capability  of 
providing  status  information  to  the  Ground  Control  system  that  will  permit  an 
availability  decision  to  be  performed. 

If  the  ramp  area  is  unavailable  a  "Hold"  instruction  must  be  issued  and 
the  sensor  system  should  recognize  compliance  with  this  instruction.     If  the  ramp 
area  is  available,  a  clearance/handoff  may  be  issued  or  the  lack  of  a  "Hold"  instruc- 
tion can  be  interpreted  by  the  pilot  (as  is  done  at  present)  that  the  ramp  area  is 
available.     Verification  of  the  event  that  the  arrival  aircraft  is  proceeding  into  the 
ramp  area  should  be  made  prior  to  the  last  location  at  which  the  arrival  aircraft 
can  be  "held".     This  location  might  be  on  one  of  the  Inner  Links  immediately  pre- 
ceding the  R/l  link  to  be  used  by  the  "Arrival",   or  possibly  the  I/O  link  directly 
outside  of  the  ramp  entrance.     The  occurrence  of  this  situation  should  be  furnished 
to  the  Ramp  Control  system  for  scheduling  purposes. 

While  taxiway  routing  requirements  for  "Arrivals"  are  such  that  only 
the  ramp  area  must  be  specified,  the  handoff  function  can  be  most  expeditiously 
performed  if  specific  gate  information  is  available.     For  example,   departure  air- 
craft close  to  the  main  terminal  buildings  and  in  "pushback"  would  not  block  "Arriv- 
als" with  gates  farther  out  on  the  concourse  fingers.     It  appears,  therefore,  that 
the  interface/handoff  function  may  impose  on  the  Ramp  Control  system  the  necessity 
of  some  type  of  "block"  or  space  availability  estimation  within  the  narrow,  and  often 
crowded,   ramp  areas. 

Sensor  requirements  for  recognition  of  entrance  demand,   since  predic- 
tion of  entrance  time  is  desired,  are  not  stringent  in  terms  of  position. 

We  have  chosen  a  value  between  50  feet  and  100  feet  which  should  have 
only  a  small  impact  upon  the  estimated  ramp  arrival  time.     Measurement  of  the 
existing  velocity  of  the  aircraft,   except  for  movement  detection  purposes,   cannot 
be  really  used  for  prediction  purposes  due  to  time  variations  arising  from  "turns,  " 
"braking,  "  etc. 


4.2.3.8        Routing  Control  Function  G 

The  operational  logic  for  the  Routing  Control  function  is  shown  in  Fig- 
ure 4-6.    The  three  major  components  of  this  process  are  those  of  Route  Selection, 
Route  Issuance,  and  Route  Verification.     Route  Selection  depends  upon  the  particu- 
lar runway  configuration  in  use,  the  origin  and  destination  of  the  taxiing  aircraft, 
and,   in  some  cases,  the  aircraft  equipment  type.    Standard  routes  are  used  in  most 
cases  by  the  Inbound  and  Outbound  Ground  Controllers;  these  have  been  described  in 
the  previous  working  paper  on  this  contract.     Issuance  of  the  route  (and  confirma- 
tion by  the  pilot  that  he  understands  it)  takes  place  via  voice  communications. 

While  it  is  desirable  that  verification  of  the  specified  route  be  per- 
formed by  the  Ground  Controllers,  this  in  many  cases  is  extremely  difficult  because 
of  the  aircraft  load;  therefore,   extensive  reliance  is  placed  upon  the  fact  that  pilots 
are  quite  familiar  with  the  taxiway  network  at  O'Hare.     It  should  be  noted  that,  as 
part  of  our  survey  effort  of  visual  guidance  equipment  at  O'Hare,  there  are  only  a 
limited  number  of  signs  that  actually  indicate  to  a  pilot  where  he  is;  most  signs 
provide  destination  type  rather  than  location  information. 

The  designated  route  for  a  particular  aircraft  can  serve  a  major  role 
in  the  conflict  management  function;  specifically  it  would  be  used  for  conflict  de- 
tection purposes.  Without  this  data,  appreciably  more  data  processing  would  be 
required  for  the  conflict  detection  "job". 

In  the  semi-automated  system  it  can  be  seen  that  a  major  problem  in 
inputing  route  data  will  exist  if  it  is  required  that  the  controller  enter  this  data  at 
the  time  it  is  issued  to  the  pilot.    An  alternate  approach,  whereby  the  information 
in  the  data  base  is  presented  to  the  controller  for  a  particular  operation  and  he  then 
selects  one  of  perhaps  two  computer-displayed  routes  via  a  binary  entry  device, 
appears  to  be  a  more  desirable  mode  of  operation  which  is  compatible  with  the 
needs  of  a  semi-automated  ground  control  system. 

It  is  envisioned  that  the  surveillance  sensor  data  will  be  utilized  for 
monitoring  the  actual  route  followed  by  either  the  Arrival  or  Departure  aircraft. 
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Upon  recognition  that  an  incorrect  route  is  being  followed  by  an  aircraft,  a  flag 
of  some  type  will  call  this  event  to  the  attention  of  the  controller.  At  this  time  he 
will  then  take  the  appropriate  action  which  may  involve  a  keyboard  entry  device  of 
some  type  for  route  modification  purposes.    Moreover,  since  the  specific  turnoff  of 
an  arrival  from  a  runway  cannot  be  firmly  established  until  effected,  this  may  im- 
pact on  the  route  to  be  followed  by  Arrival  aircraft.     Such  a  situation  may  require 
an  input  either  by  the  controller  or  from  the  data  processing  system  of  the  actual 
turnoff  exercised  by  the  incoming  aircraft.     The  "Turnoff  Recognition  or  Predic- 
tion" function  performed  here  as  part  of  the  Local  Control  System  (at  handoff),  or 
as  part  of  the  Ground  Control  System,   can  then  serve  as  an  input  to  the  route  selec- 
tion process  for  arrivals. 

In  estimating  the  positional  accuracy  required  by  route  verification, 
the  criteria  used  is  to  assure  link  detection  (clear  of  the  intersections  at  both  ends) 
for  most  of  the  links  for  which  sole  link  occupancy  is  possible.    These  links  are 
represented  largely  by  the  O/O  and  S/O  taxi  ways  (see  Appendix  A).    The  O/O  are 
largely  over  600  feet  long  and  the  S/O  range  from  400-700  feet.    If  a  length  of 
550  is  chosen  as  representative  then  an  accuracy  of  20  feet  (see  Appendix  C)  is 
adequate  with  modest  sampling  rates. 

4. 2.  3.  9        GCS  Conflict  Management  (Function  H) 

Conflicts  may  be  defined  as  those  situations  wherein  there  is  an  appar- 
ent demand  for  the  same  facility  (i.  e. ,  link  or  node)  by  two  or  more  aircraft  over- 
lapping in  time.     Actual  conflicts,   of  course,  will  almost  never  occur;  while  in 
most  cases  they  are  resolved  by  the  controller,  the  pilot  of  either  aircraft  can  be 
expected  to  take  the  necessary  evasive  action,   i.  e. ,   stop,   slow  down,   request  in- 
structions, etc. 

Conflicts  for  use  of  taxiway  facilities  may  occur  between  two  taxiing 
aircraft  or  may  arise  between  a  taxiing  aircraft  and  aircraft  "in"  the  interfacing 
Local  Control  and  Ramp  Control  Systems.     R/W  Crossing  Control,  wherein  the 
crossing  node  is  time  shared  by  both  the  Local  and  Ground  Controller,  is  an  example 


of  the  latter.    Other  examples  may  occur  due  to  Ramp  Area  activity,  i.e.  ,  the  re- 
lease of  aircraft  from  the  Ground  Control  Departure  Q  (or  Ramp  Area)  must  con- 
sider nearby  taxiing  aircraft.    A  similar  situation  exists  for  Function  F  (Interface/ 
Handoff  to  Ramp  Control)  wherein  Ramp  Area  availability  may  necessitate  a  taxi- 
way  "Hold". 

The  Conflict  Management  function  may  be  considered  to  comprise 
several  subfunctions  as  follows: 

•  Conflict  Search  and  Recognition 

•  Presentation  of  Situation  to  Controller 

•  Resolution  Verification 

•  Monitoring  of  Ongoing  Conflicts 

We  have  previously  identified  five  types  of  conflicts  which  occur  in  the 
Ground  Control  System.     Of  these  only  the  Taxiway/Taxiway  conflict  is  non-deter- 
ministic in  nature;  all  other  conflicts  can  occur  only  because  an  aircraft  is  demand- 
ing a  specific  type  of  service.     A  summary  of  these  conflict  types  is  given  in  Table 
4-2.     The  semi-automated  system  concept  is  based  upon  the  premise  that  Conflict 
Resolution  is  performed  in  all  cases  by  the  controller.     The  accomplishment  of  the 
other  component  of  Conflict  Management  will  depend  upon  the  particular  conflict 
involved.     These  factors  are  discussed  separately  below  for  each  of  the  five  con- 
flict types. 

Table  4-2.    Summary  of  Conflict  Types  (Ground  Control  System) 


Conflict  Type 

Priority 
Aircraft 

Conflict  Effect 

Relative  Occurrence 

Ramp  Exit 

Taxiing  A /C 

Delay  to  Departure 

Medium 

Taxiway/Taxiway 

- 

Low 

R/W  Crossing 

Landing  A/C 

Delay  to  Taxiing  A/C 

Medium  (R/W  Con- 
figuration Dependent) 

Turnoff-Generated 

Landing  A/C 

Delay  to  Taxiing  A/C 

Low 

Ramp  Entrance 

Ramp  Departure 

Delay  to  Arrival 

High 

4. 2.3.  9. 1    Ramp  Exit  Conflict  (Function  H-l) 

Upon  recognition  of  "demand",   i.  e. ,  an  A/C  in  the  Ground  Control  De- 
parture Q,  it  is  necessary  to  perform  a  Conflict  Search  of  the  "Active"  Aircraft  in 
the  immediate  vicinity  of  the  particular  Ramp  Area.     If  there  are  "Active"  aircraft 
(moving)  in  a  manner  that  would  conflict  with  the  Departure  aircraft,  this  situation 
could  be  presented  to  the  controller  so  that  he  would  recognize  the  end  of  the  con- 
flict and  release  the  Departure.    Alternately,   a  "denial"  signal  could  be  presented 
to  the  controller  which  would  change  to  a  "Go"  signal  upon  end  of  the  conflict.     Pre- 
diction of  future  position  of  the  taxiing  aircraft  (causing  the  scheduling  type  conflict) 
would  be  required. 

4.2.3.9.2    R/W  Crossing  Conflict  (Function H-2) 

This  conflict  can  only  occur  if  two  events  are  satisfied,  i.  e. ,  an  air- 
craft is  "close"  to  crossing  a  R/W  and  an  aircraft  (under  Local  Control)  is  within 
"X"  seconds  of  the  R/W  Crossing.     Conflict  search  and  recognition  based  upon  run- 
way surveillance  data  need  only  be  performed  when  necessary.    This  particular 
type  of  conflict  involving  only  two  aircraft  appears  readily  suitable  for  a  GO/NO- 
GO  type  display. 

4.  2. 3.  9. 3    Taxiway/Taxiway  Conflict  (Function  H-3) 

While  this  type  of  conflict  seldom  occurs  it  does  impose  the  greatest 
surveillance  load  upon  the  controllers  in  the  present  system.     Being  non-determin- 
istic it  is  necessary  to  continually  perform  a  search  for  potential  conflicts  for  all 
"Active"  aircraft.     This  search  rate  should  be  such  that  it  does  not  unduly  penalize 
the  system  response  time.    If  a  one-second  search  rate  is  employed  and  there  are, 
say,   15  Active  aircraft  "in"  the  Ground  Control  System,  then  all  possible  pairs  of 
-J-  =  105  would  have  to  be  examined  every  second  in  a  system 
without  other  control  logic.     This  number,  of  course,  can  be  substantially  reduced 
by  using  location  algorithms,  etc.  ,   so  that  only  pairs  of  aircraft  within  a  certain 
distance  of  each  other  or  at  a  given  location  are  evaluated.    In  fact,  this  criteria 


should  probably  be  employed  in  controlling  the  surveillance  activities.     Upon  rec- 
ognition of  a  conflict  of  this  type,  the  situation  may  be  displayed  to  the  controller 
in  a  manner  perhaps  showing  the  predicted  position  of  each  aircraft  involved  in  the 
projected  conflict  over  the  next  15  seconds  to  25  seconds.     Upon  the  controller  tak- 
ing action,   i.  e.  ,    "holding"  an  aircraft,   it  is  envisioned  that  the  surveillance  sys- 
tem would  recognize  that  one  of  the  aircraft  has  stopped  (Movement  Detection). 

Monitoring  of  on-going  conflicts  is  essentially  a  subfunction  directed 
toward  recognition  of  the  end  of  a  conflict  (scheduling  or  otherwise)  so  that  an  in- 
dication may  be  given  to  the  controller  that  a  "Hold"  aircraft  must  be  changed  into 
an  "Active"  status. 

While  further  effort  is  required  in  this  area  to  define  the  necessary 
surveillance  requirements,  the  results  given  in  Appendix  E  indicate  that  values  of 
ax  of  50  ft  will  result  in  prediction  time  errors  of  about  2  seconds.     Measurement 
of  present  velocity  of  the  aircraft  does  not  appear  to  be  a  significant  parameter  for 
prediction  of  future  A/C  position  because  of  acceleration/deceleration  effects  over 
the  prediction  period  of  15  seconds  to  30  seconds.     It  is  currently  believed  that,   if 
the  aircraft  is  recognized  as  "moving",   estimated  taxi  velocities  can  be  assigned 
to  the  aircraft  depending  upon  its  location.     For  example,   in  the  Inner /Outer  area 
a  nominal  taxi  speed  of  perhaps  12  knots  would  be  used  for  conflict  estimation  pur- 
poses.    On  links  closer  to  the  runways  values  of  taxi  speed  of  20  knots  to  25  knots 
might  be  used. 

Aircraft  on  the  same  highway,  i.  e.  ,  maintaining  headway  between  each 
other,  would  not  be  considered  to  be  in  conflict  since  this  is  the  pilot's  responsibil- 
ity.    This  should  substantially  reduce  the  number  of  apparent  conflicts. 

4.  2.  3.  9.  4    Turnoff-Generated  Conflicts  (Function  H-4) 

These  are  very  similar  to  those  of  the  R/W  Crossing  type  with  the  ex- 
ception that  the  actual  turnoff  cannot  be  positively  estimated  in  advance.  "Turnoff 
Recognition",   i.  e.  ,   change  of  heading  of  the  landing  aircraft,  may  be  an  event  which 


could  trigger  this  conflict  recognition  process.    Aircraft  on  the  parallels  in  the  vi- 
cinity of  the  turnoffs  would  then  be  presented  to  the  controller  who  would  inform 
them  to  "hold"  if  necessary.     It  is  not  expected  that  this  conflict  will  occur  often. 
Alternately,  the  situation  existing  on  the  runway/parallel  could  be  presented  to  the 
Ground  Controller  when  the  landing  aircraft's  speed  had  dropped  below,   say,   60 
knots.     This  would  indicate  whether  any  action  was  required.    Acceptance  of  the 
landing  aircraft  into  the  taxi  system  (Function  D)  and  recognition  thereof  would  in- 
dicate the  "end"  of  this  type  of  conflict. 

4.2.3.9.5    Ramp  Entrance  Conflict  (Function  H-5) 

This  conflict  is  caused  by  Departure  A/C  in  the  Ramp  Area  essentially 
making  it  unavailable  for  an  Arrival  aircraft  that  is  within  perhaps  30  seconds  to 
45  seconds  of  entry.    It  is  primarily  a  scheduling  problem  which  occurs  often  and 
has  been  discussed  under  Function  F.     It  is  not  envisioned  that  this  type  of  conflict 
will  impose  stringent  requirements  upon  the  surveillance  needs  of  the  Ground  Con- 
trol System.     However,   it  will  impose  additional  requirements  on  the  Ramp  Control 
System,   i.  e. ,  the  need  to  distinguish  between  Arrivals  and  Departures  and  possibly 
the  desirability  of  recognizing  approximate  location  (in  the  Ramp  area)  of  Depar- 
tures in  the  Pushback  mode. 

4.2.4  Operational  Requirements 

The  principal  operational  requirements  that  have  to  be  satisfied  by  the 
semi-automated,   real-time  Ground  Control  System  are: 

1.  Compatibility  with  the  current  Tower  Ground  Control  procedures 
and  methodology. 

2.  Output  indications  to  aid  and  augment  Ground  Controller  perform- 
ance and  reduce  Ground  Controller  workload. 

3.  Output  indications  to  permit  safe  and  efficient  control  of  aircraft 
under  visibility  conditions  in  which  the  pilot  can  see  to  taxi  but 
controller's  visibility  is  limited. 


4.  Output  indications  are  to  be  in  the  form  of  displays  oriented  to  the 
specific  function  to  be  performed,   i.  e.  ,   selective  vs  all  inclusive. 

5.  "Job"  scheduling  primarily  arranged  by  the  Ground  Control  Sys- 
tem,  not  Controller.     Controller  to  have  override  capability. 

6.  The  Ground  Control  System  must  operate  satisfactorily  with  the 
maximum  peak  aircraft  traffic  load. 

During  normal  (daytime)  weekday  hours  under  good  weather  conditions 
the  hourly  aircraft  load  on  the  total  GCS  at  O'Hare  has  been  found  to  range  from  8 
to  12  (aircraft -hours  per  hour)  although  a  peak  value  of  15.  4  was  observed  during 
the  survey  efforts.     These  values  occurred  during  airport  operational  rates  of  120- 
140/hour.     These  values  do  not  include  A/C  awaiting  entry  into  the  taxi  system  (at 
the  R/Ws  or  Ramp  areas)  nor  do  they  include  A/C  in  the  Local  Control  Departure 
Q  area.     Previous  studies  have  shown  that  the  ratio  of  short  term  "peaks"  over  a 
5-minute  interval  with  respect  to  the  hourly  load  may  range  from  1.  5  to  2.  0. 
Translation  of  the  above  to  an  operational  level  of  200  operations/hour  gives  hourly 
"load"  values  of  — —  x  13  (an  estimate)  or  20;  in  peak  5-minute  periods,   30-40  air- 
craft would  be  "in"  the  system  either  taxiing  to  or  from  the  ramp,   in  the  Penalty 
Box,  or  in  a  "Hold"  condition.     As  a  check  on  the  above  conclusions  the  following 
analysis  may  be  compared  with  the  above. 

If  it  is  assumed  that  A/C  movement  on  the  airport  past  fixed  points  or 
segments  can  be  modeled  by  a  Poisson  distribution,  then  at  99.  6  percent  probabil- 
ity no  more  than  4  A/C  (or  a  queue  of  3)  will  be  attempting  to  pass  at  one  instant  of 
time. 

If  also  the  airport  is  working  fairly  smoothly  at  maximum  capacity 
(probably  no  more  than  200  operations /hour  at  O'Hare)  the  above  conditions  can  be 
expected  to  occur  over  all  major  elements  of  A/C  movement,   i.  e.  ,   expected  A/C 
densities  are: 


Ramp  Departure  Queues  3 

Departures,   Inner/Outer  4 

Departures,   Taxiways  8  (  2  RW) 

RW  Departure  Queues  (Local  Control  De- 
parture Q)  6  (2  RW) 

RW  Effective  Occupancy  4  (4  RW) 

Arrivals,   Taxiways  8  (2  RW) 

Arrivals,   Inner/Outer  4 

Arrivals,  Staging  Area  3 

Total  40 

For  individual  controller  positions,  these  totals  relate  to: 

Arrival  Ground  Control  15 

Departure  Ground  Control  15 
Local  Control  North  5 

Local  Control  South  5 

From  the  above  it  is  estimated  that  the  GCS  should  be  capable  of  main- 
taining "track"  on  about  50  aircraft  (25  percent  margin)  at  one  time. 

In  addition  we  are  interested  in  the  rate  at  which  tracks  must  be  estab- 
lished.    Tracks  must  be  initiated  for: 

A/C  Entering  from  Ramp  Area  90-100/hr. 

Arrival  A/C 

Landing/Turnoffs  90-100/hr. 

Hangar/Popups  10-20/hr. 

Penalty  Box  Exits  10-20/hr. 

Total  240/hr. 

Special  needs  (other  vehicles,   reacquisition,  etc. )  may  be  expected  to 
lis  by  25  percent  or  1 
or  10  track  initiations/minute. 


4.3  MODULE  DESCRIPTION 

4.  3.  1  Overall  Characteristics 

The  GCS  Module  involves  a  Data  Acquisition  System  (DAS),   a  Data 
Processing  System  (DPS)  and  inputs/outputs  to  and  from  the  Controller  via  Dis- 
plays and  simple  keyboards  as  shown  in  Figure  4-7. 

The  DAS  can  be  a  single  scheme  such  as  GEOSCAN  or  an  integration  of 
separate  elements.  However,  it  should  respond  to  "Job"  scheduling  demands  of  the 
DPS  and  provide  A/C  data  as  required. 

The  DPS  provides  all  the  machine  elements  of  the  Control  Functions 
and  data  for  displays  to  the  Controllers  and  accepts  Controller  Action  indications. 
In  addition,  the  DPS  interfaces  with  the  RCS  and  the  LCS  by  maintenance  of  A/C 
files  as  the  A/C  moves  between  control  of  the  three  modules. 

Controller  displays  are  to  be  based  upon  the  discrete  requirements  of 
the  controller  position,   i.  e.  ,   Arrival  vs  Departure.     Typically  two  displays  are 
envisioned,  one  an  alpha-numeric  display  indicating  A/C  awaiting  entry  from  the 
LCS  or  RCS  together  with  a  simple  A/C  file  of  A/C  in  the  system;  and  a  schematic 
display  for  conflict  situation  presentation.     A  highly  simplified  controller  entry 
device  is  required  to  indicate  controller  actions-    A/C  entry  acceptance,    "Hold" 
instruction,  handover,   etc.  ,   plus  features  for  overriding  the  "Job"  scheduling 
feature  of  the  DPS  to  obtain  a  display  of  any  specific  airport  surface  area. 

While  this  description  of  the  Ground  Control  System  has  been  based 
upon  the  use  of  a  single  data  processor,    integration  of  this  system  with  the  similar 
LCS  may  be  feasible  permitting  the  use  of  a  single  processor  for  use  of  both  systems. 

4.  3.  2  Interface  Considerations 

The  GCS  must  interface  with  the  RCS  and  the  LCS.     Interfacing  with 
the  LCS  will  involve  the  interchange  of  A/C  data  for  computing  safe  conditions  for 
Runway  Crossing  Control,   and  Handoff  A/C  file  data  for  A/C  transferring  under 
control  between  the  two  systems. 
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Figure  4-7.    GCS  Module 


Similarly  an  interface  is  required  between  the  RCS  and  the  GCS.     In 
this  instance  arrival  A/C  files  require  data  from  the  RCS  as  to  whether  the  destina- 
tion is  clear  or  whether  routing  to  the  Penalty  Box  is  required.     For  this  feature 
the  GCS  processor  must  supply  the  RCS  with  expected  time  of  the  arrival  A/C  at 
its  destination. 

For  departure  aircraft  the  RCS  must  enter  RTT  A/C  files  into  the  De- 
parture Q  of  the  GCS. 

4.  4  BENEFIT  ANALYSIS 

4.  4.  1  General 

The  major  benefits  derived  by  the  GCS  are  keyed  to  controller  work- 
load especially  under  poor  visibility  conditions.  By  reducing  controller  workload 
through  the  implementation  of  a  semi-automatic  system  the  controller  can: 

1.  Devote  more  time  (judgment)  to  individual  conflicts  requiring  his 
attention. 

2.  Maintain  alertness  for  potentially  dangerous  situations. 

3.  Work  under  high  stress  conditions  with  reduced  mental  fatigue. 

The  above  factors  probably  will  produce  situations  of  reduced  aircraft 
delay  under  peak  traffic  load  and  certainly  improve  safety  and  efficiency. 

Under  poor  visibility  conditions  controller  workload  will  be  further  re- 
duced as  the  controller  will  not  have  to  continually  call  A/C  for  position  reports  as 
is  currently  done.  In  addition,  the  feature  of  automatic  A/C  route  verification  pro- 
duces a  level  of  safety  not  available  in  the  current  system. 

Under  poor  visibility  conditions,  the  current  controller  workload  in- 
creases because: 

•  Departure  queues  become  extensive,   causing  blocking  of  Inner  and 
Outer  Links. 

•  Controllers  increase  use  of  "Holds"  for  safety  purposes  and  reso- 
lution of  taxi  conflicts  due  to  long  departure  queues. 


•  Controllers  may  not  have  normal  visual  access  to  A/C  and  may 
have  to  resort  to  Pilot  Position  Reports  and/or  ASDE  interpretation. 

•  Normal  traffic  disruption  interfering  with  Gate  Scheduling  causes 
increased  Penalty  Box  Staging  of  arrival  aircraft. 

In  addition  the  visual  displays  currently  under  consideration  for  the 
GCS  will  be  functionally  oriented  (i.  e.  ,   selective)  so  that  only  that  information  needed 
for  the  particular  function  is  displayed.     This  selective  process  is  envisioned  as 
providing  capabilities  for  display  of  portions  (ramp  exit/entrance  area;  R/W  cross- 
ings area,  turnoff  area,  etc. )  of  the  airport  as  the  need  arises.     This  selective 
process  coupled  with  the  availability  of  A/C  ID  should  permit  substantial  improve- 
ment in  the  control  process  under  poor  visibility  conditions.     As  will  be  shown 
later  in  this  section,  the  controller  workload  is  expected  to  be  reduced  by  about  30 
percent  in  conditions  of  good  visibility;  the  reduction  in  poor  visibility  should  be 
even  greater. 

The  current  extensive  controller  requirements  of  A/C  position  reports 
by  radio  communication  transactions  will  no  longer  be  required  with  the  semi-auto- 
matic system,  and  "lost"  aircraft  situations  will  be  automatically  reported  to  the 
controller. 

The  compatibility  requirement  intimates  that  operations  with  the  GCS 
will  incorporate  much  of  the  same  methodology,  radio  communication  discipline 
and  protocol,   and  flight  strip  handling  (for  departure  aircraft)  as  is  in  use  at  present. 

Controller  performance  augmentation  is  to  be  achieved  through  a  dis- 
play system  that  automatically  alerts  the  controller  to: 

Potential  taxiing  conflicts 

R/W  turnoff  conflicts 

Lost  aircraft  situations 

R/W  crossing  requirements 

Handover  situations 

Presence  of  aircraft  in  Ground  Control  Departure  Q  and  status  of 
Ramp  Exit  Areas  (Ramp  Exit  Conflict) 


4.  4.  2  Workload  Reduction 

While  controller/pilot  communications  represent  a  substantial  part  of 
the  controller's  work  load  (and  is  readily  measurable),  the  data  collection  (primar- 
ily visual  surveillance)  and  interpretation  portion  of  the  controller's  activities  are 
of  primary  significance  in  establishing  how  well  he  can  perform  the  various  control 
functions.     The  controller  can  do  some  scheduling,  or  selection,   of  which  function 
is  to  be  done  next,   i.  e.  ,  he  can  defer  a  "Handoff"  if  a  higher  priority  function  needs 
his  attention.     However,  the  scheduling  of  his  activities  is  most  strongly  influenced 
by  the  random  nature  of  aircraft  maneuvers  and  the  use  of  the  communication  chan- 
nel.    This  scheduling  process  is  supported  also  by  pilot  actions;    if  the  controller 
cannot  "handle"  an  aircraft  at  a  particular  time,  the  pilot  may  slow  down  or  wait 
for  the  controller's  actions. 

An  attempt  has  been  made  to  establish  the  total  functional  load  on  the 
overall  GCS  under  conditions  of  good  visibility.     This  estimate  is  given  in  Table 
4-3.     In  periods  of  poor  visibility,  this  functional  load  will  increase  with  the  pres- 
ent system  due  to  lack  of  surveillance  capabilities,  decreased  A/C  speeds,   etc. 
The  functional  activity  or  load  on  the  controller  is  then  estimated  in  Table  4-3  for 
a  semi -automated  system  which  not  only  provides  surveillance  inputs  for  the  con- 
troller but  provides  conflict  detection  capabilities  for  assisting  the  controller  in 
scheduling  his  activities. 

The  functional  activity  estimate  in  the  present  system  has  been  based 
upon  the  hourly  operations  rate  shown  in  the  table  (180  operations/hour).     The 
second  column,  labeled  "Conflict/Repeat  Factor",  represents  the  estimated  in- 
crease in  the  number  of  times  the  particular  function  has  to  be  performed  because 
of  conflicts,   lack  of  data,   or  controller  unavailability.     This  will  not  be  readily 
apparent  from  analysis  of  communications;  for  example,  a  controller  when  seeing 
a  ramp  exit  conflict  simply  goes  on  to  another  function  without  talking  to  the  pilot, 
then  reevaluates  the  situation  again,   etc.     Translation  of  the  modified  hourly  activ- 
ity rate  to  the  load  occurring  in  a  "peak"  minute  has  been  based  upon  factors 
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determined  in  previous  studies  for  the  FAA  where  the  ratio  of  "peaks"  in  a  5- 
minute  period  to  the  hourly  load  was  found  to  range  from  1.  3  to  about  1.  7.     The 
values  of  functional  activity  in  the  "peak"  minute  have  been  summed  for  "Depar- 
tures" (Functions  A  and  B),    "Arrival"  and  Common  Factors  (Functions  G  and  H). 
The  total  peak  load  of  34  functions  per  minute  has  then  been  adjusted  downward  by 
a  factor  of  between  0.  5  and  0.  6  since  all  functions  will  not  "peak"  at  the  same  time. 
The  resulting  functional  activity  of  15-20  per  peak  minute  does  not  include  the  func- 
tions of  route  verification  (part  of  Function  G)  and  the  rapid  and  continuing  surveil- 
lance of  all  aircraft  for  random  conflicts  (Function  H-2).     It  is  believed  that  heavy 
reliance  is  placed  upon  the  pilot  for  accomplishment  of  these  functions. 

One  significant  aspect  of  the  functional  activity  analysis  are  the  appar- 
ent larger  load  on  the  Inbound  Ground  Controller  although  no  "weighting"  of  the 
complexity  of  the  various  functions  has  been  attempted.     The  GCS  conflict  load 
represents  primarily  the  need  to  "check"  or  detect  conflicts  and  should  not  be 
interpreted  as  actual  conflict  occurrence.     This  conflict  load  (Function  H)  is  com- 
parable to  the  sum  of  the  Departure  plus  Arrival  Loan  (Functions  A  through  G  ex- 
cluding Route  Verification). 

One  may  well  ask  how  the  controller  can  handle  such  a  load.     Possible 
factors  contributing  to  this  capability  include  delay  of  non-critical  functions; 
knowledgeable  pilots  familiar  with  O'Hare  (low  G.  A.  levels);  and,  perhaps  most 
important,  the  ability  of  a  controller  to  remember,   select,   collect,   and  interpret 
visual  data  (A /C  orientation,  markings,  movement,   etc.). 

In  periods  of  low  visibility  when  the  benefits  of  a  semi-automated  sys- 
tem would  be  greater,  the  data  processing  system  and  displays  must  provide  as 
mich  support  to  the  controller  as  possible.  This  support  is  envisioned  as  provid- 
ing extensive  capability  for  conflict  detection  and  function  scheduling  so  that  con- 
troller attention  may  be  directed  toward  the  highest  priority  functions.  With  such 
an  approach  functions  will  not  disappear.  Their  need  will  instead  be  determined 
within  the  computer  (with  controller  override)  so  that  repeats  of  functions  or 


surveillance  for  conflicts  can  be  substantially  reduced.     For  example,   in  the  R/W 
crossing  conflict  the  controller  needs  simply  a  GO/NO-GO  indication;  with  proper 
surveillance  data  and  processing  the  need  for  controller  surveillance  of  all  R/W 
crossing  situations  may  be  substantially  reduced.     This  rationale  has  been  used  to 
develop  an  estimate  of  the  functional  activity  required  of  the  controller  with  a 
semi-automated  system  and  is  shown  in  the  last  column  of  Table  4-3.     It  has  been 
concluded  that  such  a  system  could  reduce  the  functional  activity  load  to  approxi- 
mately 2/3  of  that  in  the  present  system  under  good  visibility.     Comparison  with 
the  present  system  under  poor  visibility  conditions  cannot  readily  be  made;  how- 
ever,  it  is  believed  that  the  workload  reduction  benefits  will  be  even  more  substan- 
tial. 


SECTION  5  -  DEVELOPMENT  OF  A  LOCAL 
CONTROL  SYSTEM  (LCS)  CONCEPT 


5.  1  INTRODUCTION 

The  semi-automated  Local  Control  System  (LCS)  will  provide  the  Local 
Controller(s)  with  improved  data  surveillance,  data  processing,  and  display  capa- 
bilities for  increasing  runway  capacities,    reducing  his  workload,   and  providing  ad- 
ditional safety  margins  under  both  VFR  and  IFR  conditions.     The  proposed  concept 
is  one  wherein  measurement  of  both  position  and  velocity  information  is  used  to 
predict  future  aircraft  position.     This  prediction  capability  is  then  used  within  a 
computer  to  satisfy  a  variety  of  functions  such  as  conflict  detection,   spacing  con- 
trol,  R/W  crossing  control,   etc.     The  outputs  to  the  controller  in  this  semi-auto- 
mated concept  are  expected  to  range  from  simple  GO/NO-GO  types  to  available 
time  indications  as  well  as  recommendations  for  specific  action  (speed  change  for 
second  arrival,   etc.  ). 

The  proposed  concept  of  this  real-time  system  is  still  under  develop- 
ment; the  emphasis  of  this  working  paper  is  therefore  directed  primarily  toward 
the  requirements  dictated  by  the  semi-automated  concept. 

The  LCS  system  is  that  described  in  the  Statement  of  Work  as  the  RASE 
(Runway  and  Approach  Surveillance  Equipment).     It  should  include,  however,   all 
components  necessary  for  a  complete  system  from  sensors  to  displays. 

5.  2  REQUIREMENTS  ESTIMATION 

5.  2.  1  General 

The  Local  Control  System  differs  from  the  Ground  Control  System 
(GCS)  in  that  the  traffic  is  more  "ordered"  and  predictable.     In  addition,  the  num- 
ber of  possible  aircraft  routes  is  appreciably  smaller  than  in  the  GCS.     These  dif- 
ferences may  therefore  permit,  and  for  some  functions  require,  that  the  informa- 
tion presented  to  the  controller  is  more  than  a  GO/NO-GO  type  of  indication. 


Specifically,  the  apparent  needs  for  Spacing  Control  (Function  F)  are  such  that  a 
computer-derived  recommendation  for  a  speed  change  would  appear  desirable. 

As  in  the  GCS,  an  Aircraft  Movement  Profile  has  been  used  to  esti- 
mate the  required  prediction  intervals  and  sensor  performance  requirements.    A 
summary  of  these  profile  characteristics  is  presented  in  Table  5-1.     It  should  be 
noted  that  this  table  is  by  no  means  complete;  additional  data  is  highly  desirable  if 
proper  algoithms  are  to  be  developed  for  the  actual  system. 

To  illustrate  the  several  decision-making  functions  which  could  be  ex- 
pedited by  a  semi-automated  LCS,  four  separate  cases  may  be  cited.    These  are: 

Case  1  -  Taxiway/Runway  Crossing  Control  -  Input  to  GCS  from 
Function  J 

Case  2  -  Arrival/Departure  Sequencing  (Separate  Crossing  Runways)  - 
Functions  L-l  and  L-2 

Case  3  -  Control  of  Arrivals  on  Intersecting  Runways  -  Function  L-3 

Case  4  -  Arrival/Departure  Sequencing  during  mixed  operations  on  the 
same  runway  -  Function  K 

The  functional  identification  of  these  cases  are  set  forth  later  in  this 
section  under  the  several  types  of  possible  conflicts.     It  should  be  noted  that  other 
cases  also  exist. 

Examples  of  the  above  four  control  situations  are  shown  in  Figures 
5-1,   5-2,   5-3,  and  5-4  for  O'Hare  Airport.    All  have  been  observed  during  our 
work  for  TSC.     In  Case  1,  the  Departure  Ground  Controller  must  decide  when  to 
release  an  aircraft  across  the  active  runway.     Cases  2  through  4  involve  only  the 
Local  Controller. 

In  Case  2  the  release  of  Departures  (Clear  to  Takeoff)  by  Local  Con- 
trol is  based  upon  the  status  of  the  Arrival  runway  AND  the  intersection.     The 
most  common  method  of  release  appears  to  be  based  upon  visual  recognition  of 
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Figure  5-1.    Arrivals  on  Intersecting  Runways 
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Figure  5-2.    Arrival /Departure  Sequencing  Mixed  Operations  on  Same  Runway 


Departure  A/C  going  to  9R 


Figure  5-3.     Typical  Taxiway /Runway  Crossings 
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Figure  5-4.    Arrival  /Departure  Sequencing  Separate  Crossing  Runways 


an  Arrival  passing  through  the  intersection,  *  or  "marking"  the  time  when  the 
release  command  can  be  given.     This  method  of  release  of  a  Departure  after  an 
Arrival  works  well  in  good  visibility;  release  of  a  Departure  before  an  Arrival  is 
not  as  efficiently  accomplished  with  visual  cues. 

In  Case  3  we  have  observed  situations  where  occasional  Arrivals  will 
use  a  runway  other  than  the  primary  Arrival  runway.     The  Controller  must  prevent 
conflicts  at  the  intersection  of  the  two  runways.    The  prediction  of  this  possibility 
cannot  be  made  to  a  high  degree  of  accuracy  and  can  represent  a  high  risk  situation. 

In  the  mixed  operations  of  Case  4  (Arrivals  and  Departures  on  a  single 
runway)  the  Local  Controller  must  release  or  clear  an  aircraft  from  the  LC 
Departure  Q  to  the  runway  (Function  A)  and  then  clear  it  to  takeoff  (Function  B). 
These  instructions  may  in  some  cases  be  combined  in  a  single  "contact".     The 
Local  Controller  follows  a  similar  procedure  in  performing  this  function  to  that 
described  in  sequencing  Arrival/Departures  on  intersection  runways  except  that 
the  margin  for  error  is  reduced  and  the  effect  of  pilot  response  time  becomes  more 
significant. 

The  common  parameter  in  these  Controller  decisions  is  the  need  for  a 
prediction  of  a  "time"  at  which  an  event  will  occur — for  example,  an  Arrival  reach- 
ing an  intersection.     In  the  absence  of  any  significant  tools  to  make  this  prediction, 
the  capacity  of  the  runways  must  suffer  in  order  to  maintain  adequate  safety  levels. 
If  simple  and  accurate  prediction  methods  are  available  to  assist  the  Controller, 
both  capacity  and  safety  can  benefit. 


*A  "Heavy"  Arrival  may  restrict  usage  of  some  intersections  to  2  minutes  after 
passage  of  the  "Heavy"  due  to  wake  turbulence  effects. 


To  predict  aircraft  future  position,  velocity  accuracy  is  appreciably 
more  important  than  position  accuracy  for  runway  surveillance  purposes.     The 
velocity  parameter  becomes  of  even  greater  significance  when  periods  of  decelera- 
tion or  acceleration  occur.     From  rough  position  and  accurate  velocity  data,   a 
prediction  may  be  made  of  the  earliest  possible  time  an  aircraft  can  be  at  a  future 
location,   i.  e. ,   an  intersection.     Continuous  computation  of  this  minimum  predicted 
Arrival  time  can  then  be  used  to  establish  a  "denial  window"  (or  control  red  lights) 
for  the  particular  operation  involved. 

The  wide  range  of  variables  (aircraft  type,  pilot  differences,  turnoff 
locations,  weather,  etc. )  produce  a  wide  range  of  runway  occupancy  values  which 
cannot  be  readily  estimated  by  the  controller. 

In  Appendix  F,  the  aircraft  movement  profile  for  landing  aircraft  has 
been  examined.     Theoretical  and  experimental  results  indicate  that  substantial 
benefits  could  be  obtained  through  the  use  of  prediction  techniques  for  Runway 
Crossing  control  purposes.     Sensor  performance  requirements  for  the  above  con- 
flict as  well  as  other  conflict  types  are  developed  in  paragraphs  4.2.3  and  5.2.3. 

In  the  proposed  LCS,  velocity  measurements  are  of  major  importance. 
What  is  even  more  important  is  the  use  made  of  this  data — in  many  cases  it  must 
be  processed  within  a  computer  to  produce  a  "time"  parameter  since  the  use  of 
speed  values  by  themselves  or  even  with  position  data  is  highly  questionable. 

5.  2.  2  Functional  Requirements  and  Operational  Logic 

The  functions  to  be  performed  by  the  proposed  semi-automated  Local 
Control  System  have  been  derived  from  a  detailed  study  of  existing  operational  pro- 
cedures and  problems.     The  control  functions  have  been  classified  into  those  per- 
formed for  Departures,  those  performed  for  Arrivals,  and  those  Common  to  both 
of  the  above  types  of  operations.     Four  major  functions  have  been  identified  for 
Departure  aircraft.     These  are: 


A.  Clearance  of  aircraft  from  Departure  Q  to  runway 

B.  Clearance  of  aircraft  for  takeoff 

C.  Departure  routing  control 

D.  Handoff  to  TRACON 

Four  control  functions  have  also  been  defined  for  Arrival  aircraft. 


E.  Acceptance  of  handoffs  from  Approach  Control 

F.  Spacing  control 

G.  Landing  control 

H.  Handoff  to  Ground  Control 

The  Common  control  functions  are  as  follows: 

J.      Runway  status  monitoring 

K.     Single  runway  conflict  management 

L.     Intersection  runway  conflict  management 

These  control  functions  are  summarized  in  Table  5-2;  in  addition,  the 
interfaces  required  with  the  other  portions  of  the  ATC  system  are  indicated.  The 
sequence  of  events  and/or  interacting  functions  have  also  been  indicated  in  order 
for  each  of  the  functions.  A  qualitative  identification  of  the  type  of  data  required 
by  the  controller  is  indicated  in  this  table.  In  addition  the  estimated  performance 
requirements  which  are  developed  later  in  this  section  have  been  summarized  on 
this  table. 

The  operational  logic  or  interaction  between  the  11  required  control 
functions  of  the  semi-automated  Local  Control  System  is  depicted  in  Figure  5-5. 
On  the  left  side  of  this  figure  are  those  control  functions  dealing  with  Departures 
while  the  right  side  of  the  figure  shows  the  control  functions  performed  for  Arrival 
aircraft.     In  the  center  of  this  figure  the  conflict  management  functions  (K  and  L) 
and  their  associated  sub-conflict  types  are  shown  to  illustrate  the  manner  in  which 
they  interact  with  the  functions  performed  for  Arrivals  and  Departures  respectively. 
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This  figure  depicts  the  overall  logic  between  the  various  control  functions;  the  de- 
tailed examination  of  each  function  provides  further  breakdown  of  the  operational 
logic  in  the  section  on  Performance  Requirements. 

It  should  be  noted  that  the  function  of  dual  approach  monitoring  cur- 
rently performed  in  the  IFR  room  has  not  been  included  in  the  proposed  system. 

5.  2.  3  Performance  Requirements 

5.  2.  3.  1         General 

The  following  sections  examine  each  of  the  functions  to  be  performed 
by  the  LCS  in  order  to  determine  the  performance  requirements  or  characteristics 
of  the  data  needed  by  the  Controller  and/or  data  processing  system  to  properly 
perform  the  specified  function.     Primary  emphasis  is  on  the  desired  character- 
istics of  the  surveillance  sensor  (s),  recognizing   that  there  will,   of  course,  be 
other  inputs  to  the  data  processor.     The  information  required  is  set  forth  in  oper- 
ational terminology;  these  terms  must  then  be  related  to  the  physical  parameters 
or  maneuvers  of  the  aircraft  which  will  be  determined  by  the  surveillance  sensors. 
For  the  11  functions  of  the  LCS  the  information  needed  is: 


OPERATIONAL  DATA 

Link  Occupancy/Binary  Heading 

Movement  Detection 

Turn  Recognition/Heading 

Airborne  Position 

Airborne  Velocity 

Airborne  Heading 

"OFF"  or  Predicted  "OFF"  Time 

Turnoff  Recognition/Prediction 

R/W  Occupancy 

Predicted  Time  Over  Threshold 

Predicted  Time  at  Crossing 

Estimated  Time  at  Crossing 


INPUTS  FROM 
SURVEILLANCE  SENSOR(S) 

Position 

Velocity 

Heading  or  Position  Velocity 

Position 

For  Heading  Computation 

Position,    Velocity,   Acceleration 
Position,    Velocity,   Heading 
Presence 

Airborne  Position/Velocity 
Airborne  Position/Velocity 
Ground  Position,    Velocity 
Acceleration 


Only  a  few  of  these  operational  data  elements  are  needed  for  each  func- 
tion; the  ones  selected  are  those  believed  to  be  of  primary  significance  for  replac- 
ing or  supplementing  the  process  where  applicable.     Current  prediction  capabilities 
based  upon  position  vs  time  (for  example,   "location  above  the  horizon"  vs  time  for 
an  incoming  Arrival)  are  believed  to  be  quite  limited  in  the  present  system. 

Resolution  performance  requirements  have  not  been  discussed  in  the 
specific  sections  which  follow  since  aircraft  under  Local  Control  are  well  sepa- 
rated except  at  their  entry  into,  and  exit  from,  the  area  of  responsibility  of  the 
Local  Controller.     No  need  is  seen  at  this  time  to  resolve  or  track  the  individual 
aircraft  in  the  Local  Control  Departure  Q.     However,   resolution  of  an  aircraft 
leaving  this  Q  will  require  resolution  capabilities  of  perhaps  100  ft  to  200  ft  from 
those  in  the  Q  area.     Moreover,  tracking  of  aircraft  on  the  runway  must  be  achiev- 
able with  adjacent  A/C  on  the  parallels  (approximately  400  ft  between  centers). 

5.  2.  3.  2         Clear  Aircraft  from  Departure  Q  to  Runway  (Function  A) 

The  movement  of  an  aircraft  from  a  "stopped"  condition  in  the  Local 
Control  Departure  Q  to  the  point  where  the  aircraft  is  on  the  runway  and  pointed 
in  the  take-off  direction  has  been  found  to  take  about  33  seconds.  *   An  indication 
of  "demand",  or  that  this  function  is  to  be  performed  by  the  Local  Controller,   is 
usually  based  on  the  fact  that  there  is  one  or  more  aircraft  in  the  Local  Control 
Departure  Q.     However,  it  should  be  noted  that  in  certain  cases  of  bad  weather 
some  aircraft  may  be  pushed  to  the  side  of  the  Local  Control  Departure  Q  area 
(while  they  are  waiting  for  weather  to  reach  company  minimums)  and  other  depar- 
tures in  the  Q  will  bypass  these  waiting  aircraft.     However,   in  general  the  order 
of  aircraft  in  the  Departure  Q  is  established  by  the  hand-off  process  of  the  Ground 
Controller  and,  unless  the  special  situation  as  described  above  takes  place,  the 


♦Reexamination  of  the  data  collected  at  O'Hare,  based  on  a  sample  of  88  aircraft 
and  most  of  the  runways,   indicated  a  value  for  this  parameter  of  33  seconds  with 
a  standard  deviation  of  12.  6  seconds.     The  range  of  values  was  from  12  seconds 
to  73  seconds. 


Local  Controller  knows  which  aircraft  is  at  the  head  of  the  Local  Control  Depar- 
ture Q.     Before  releasing  the  aircraft  from  the  Departure  Q  to  the  runway  takeoff 
location,  a  Local  Controller  must  also  know  that  the  runway  takeoff  area  is  avail- 
able,  i.  e.  ,  usually  by  simply  noting  that  the  previous  departure  has  left. 

Prior  to  issuing  the  clearance  to  the  runway,   Function  K-l  must  be 
performed,   i.e.,   a  single  runway  conflict  check  must  be  made  if  the  particular 
runway  is  also  being  used  for  Arrival  aircraft.     If  such  is  the  case  (i.  e.  ,   an  Ar- 
rival aircraft  for  example  has  been  accepted  by  the  Local  Controller  on  this  run- 
way),  it  will  be  necessary  to  estimate  whether  sufficient  time  is  available  to  clear 
the  Departure  to  the  runway  and  to  release  it  for  takeoff,  while  maintaining  ade- 
quate separation  between  the  Departure  and  the  incoming  Arrival.     This  conflict 
check  is  discussed  more  fully  under  Function  K-l. 

After  the  aircraft  has  been  cleared  to  enter  the  runway  it  will  be  nec- 
essary for  the  surveillance  and  data  processing  system  to  recognize  aircraft  start- 
up from  the  Departure  Q  and  movement  out  onto  the  takeoff  end  of  the  runway.     It 
is  proposed  that  Link  Occupancy  and  Movement  Detection  processes  will  be  satis- 
factory to  verify  that  Function  A  is  underway.     The  performance  requirements  are 
expected  to  be  similar  to  those  discussed  under  the  Ground  Control  System,  namely, 
one  sigma  values  are  about  3  fps  in  velocity.    If  velocity  is  obtained  from  position, 

it  is  estimated  that  a    =  10  ft  to  25  ft  depending  upon  the  sampling  rate  employed. 

x 

5.2.3.3        Clearance  of  Aircraft  for  Takeoff  (Function  B 

While  under  some  conditions  aircraft  can  be  cleared  for  takeoff  at  the 
same  time  they  are  released  from  the  Departure  Q  to  the  runway,  the  more  preva- 
lent mode  of  operations  is  to  release  the  aircraft  for  takeoff  after  they  have  moved 
to  the  runway  end  point.     The  time  at  which  this  function  is  to  be  performed  can 
therefore  be  recognized  by  the  fact  that  the  aircraft  is  indeed  at  the  runway  take- 
off point.     Function  B  may  be  considered  to  have  been  completed  when  the  aircraft 
has  begun  its  takeoff  roll.     Depending  upon  the  runway  configuration  in  use,  various 


types  of  conflict  checks  must  be  made  by  the  Local  Controller  before  the  Departure 
is  released  for  takeoff.    One  set  of  checks  involves  those  dealing  with  the  opera- 
tions on  the  particular  runway  to  be  used  by  the  Departure;  these  have  been  classi- 
fied as  single  runway  conflict  checks  and  are  described  later  under  Function  K. 
The  other  type  of  conflict  checks  (and  these  appear  to  be  more  prevalent  in  the  op- 
erations at  O'Hare)  are  those  dealing  with  operations  on  intersecting  runways. 
These  are  more  fully  described  under  Function  L. 

Recommended  heading,   or  Departure  Routing  information,  will  be  given 
by  the  Local  Controller  to  the  pilot  (often  in  the  same  contact  that  is  used  for  "clear 
to  takeoff").     It  can  be  seen,  therefore,  that  Function  B  interacts  with  Functions  C 
(Departure  Routing  Control),  K  and  L.     The  performance  requirements  of  Function 
B,   insofar  as  recognition  of  the  aircraft  being  at  the  takeoff  point,  are  approxi- 
mately the  same  as  those  set  forth  for  Function  A,  with  the  exception  that  rough 
indication  of  aircraft  heading  information  appears  to  be  desirable.     It  is  estimated 
that  most  aircraft  will  take  between  10  seconds  to  15  seconds  to  make  a  90  degree 
turn  such  as  that  required  when  an  aircraft  turns  onto  the  runway.     If  all  other 
criteria  have  been  satisfied,  it  can  be  seen  that  the  Local  Controller  could  release 
the  aircraft  for  takeoff  during  the  time  that  the  aircraft  was  completing  its  turn 
onto  the  runway;  such  a  process  might  save  4  seconds  to  6  seconds  in  the  runway 
occupancy  time  of  a  Departure.    We  have  estimated  that  aircraft  heading  informa- 
tion to  perhaps  20  degree  accuracy  would  be  useful  for  this  purpose.     The  velocity 
accuracy  requirement  is  established  by  the  fact  that  the  Controller  might  wish  to 
have  information  showing  that  the  particular  aircraft  has  indeed  stopped,   i.  e.  ,  not 
started  to  take  off  before  the  release  signal  has  been  given.     The  accuracy  require- 
ment here  is  established  by  the  need  for  Movement  Detection  or  recognition  and  is 
estimated  to  be  of  the  order  of  5  fps.    The  position  accuracy  (exclusive  of  that  re- 
quired to  estimate  velocity)  is  less  demanding  than  that  of  Function  A;    a  value  of 
perhaps  40  feet  to  50  feet  should  be  sufficient. 

Position  information  is  not  needed  for  recognition  of  the  "start-to-roll" 
process;  the  velocity  information  requires  an  accuracy  comparable  or  slightly 


higher  than  that  previously  discussed.     The  more  accurate  this  process  the  faster 
will  be  the  response  time  in  recognizing  the  beginning  of  the  takeoff  process. 

5.  2.  3.  4        Departure  Routing  Control  (Function  C) 

Since  one  of  the  major  functions  of  the  Local  Controller  is  to  provide 
separation  between  successive  departures,  it  is  desirable  to  assign  different  head- 
ings or  vectors  to  successive  departure  aircraft.     The  information  needed  by  the 
Controller,  therefore,   is  the  departure  (vector)  heading  followed  by  the  previous 
2  to  3  departures  as  well  as  the  "off"  time  of  these  aircraft.     From  this  informa- 
tion the  Controller  may  then  select  a  different  vector /heading  in  order  to  increase 
departure  separation  as  much  as  possible  early  in  the  takeoff  process.    When 
"heavy"  aircraft  are  involved,  wake  turbulence  effects  are,   of  course,   a  separate 
constraint  on  this  routing  process.     Accurate  position  and  velocity  information  is 
of  less  importance  in  this  departure  routing  and  control  function  than  is  the  meas- 
urement of  aircraft  heading  in  order  to  verify  that  the  departure  is  indeed  following 
the  assigned  vector  heading.     Estimates  of  position  accuracy  of  between  200  feet 
and  400  feet,  velocity  accuracy  of  15  feet  to  20  feet  per  second  (about  10  knots) 
should  be  sufficient  for  routing  verification.    Aircraft  heading  information  to  a  one 
sigma  value  of  perhaps  10  degrees  represents  a  preliminary  estimate  of  the  direc- 
tional data  desired  for  this  function. 

Pilot  verification  of  departure  route  assignment  is  currently  used; 
handoffs  are  often  made  during  the  time  that  the  aircraft  is  turning  to  its  assigned 
heading.     This  procedure  may  be  acceptable  in  the  semi-automated  LCS.     However, 
data  entry  of  route  followed  by  the  aircraft,   if  needed,  then  must  be  done  manually. 

5.  2.  3.  5        Handoff  to  TRACON  (Function  D) 

We  may  consider  that  Function  B  has  been  completed  when  the  aircraft 
lifts  off  the  runway  and  that  Function  D  begins  at  this  time.     Handoff  of  the  Depar- 
ture to  the  IFR  room  or  TRACON  does  not  usually  take  place,  however,  until  the 
Local  Controller  has  verified  that  the  assigned  departure  routing  is  indeed  being 


followed  by  the  aircraft.     Function  C  therefore  will  interact  with  this  function  for  a 
period  of  from  perhaps  20  seconds  to  60  seconds  depending  upon  the  aircraft  equip- 
ment type  as  well  as  the  assigned  departure  routing.     No  accurate  sensor  informa- 
tion is  required  at  the  time  of  handoff  insofar  as  the  Local  Controller  is  concerned 
since  the  evaluation  that  separation  standards  are  being  maintained  is  part  of  Func- 
tion C.     Information  on  aircraft  "Off"  time,   but  not  position  or  velocity,   is  needed 
to  provide  an  input  to  Function  J,  Runway  Status  Monitoring.     This  information  can 
be  used  by  the  Local  Controller  in  performing  the  single  runway  conflict  check  or 
to  assist  him  in  specifying  the  release  time  of  the  next  departure.     The  recognition 
of  "off"  time  or  "predicted  off"  time  for  a  departure  has  been  discussed  in  Func- 
tion K-5. 

5.  2.  3.  6        Acceptance  of  Handoffs  from  Approach  Control  (Function  E) 

Handoff  of  arrival  aircraft  from  Approach  Control  position  usually 
takes  place  in  the  vicinity  of  the  outer  marker,  4  nmi  to  6  nmi  from  runway  thresh- 
old. The  ARTS  BRITE  display  in  the  cab  is  the  tool  used  by  the  Local  Controller  to 
recognize  aircraft  position  and  identity  at  the  time  of  handoff.  Performance  of  this 
function,  therefore,  simply  requires  sufficient  position  accuracy  for  the  Local  Con- 
troller to  readily  detect  the  incoming  arrival  at  the  time  of  handoff.  A  value  of  be- 
tween 600  feet  and  1800  feet  has  been  estimated  for  this  function;  velocity  informa- 
tion is  not  needed  until  Spacing  Control  is  to  be  performed. 

5.  2.  3.  7        Spacing  Control  (Function  F) 

Normal  procedures  call  for  minimum  separation  between  Arrivals  of 
three  nautical  miles  while  under  radar  control.    In  poor  visibility  conditions,  when 
visual  approaches  are  not  possible,  the  Local  Controller  is  responsible  for  longi- 
tudinal separation  via  the  ARTS  BRITE  in  the  cab.     For  the  purpose  of  this  study, 
that  mode  of  operation  will  be  assumed  to  continue  with  no  change  due  to  ASTC 
equipments. 


5.  2.  3.  8         Landing  Control  (Function  G) 

Issuance  by  the  Local  Controller  of  the  "clear-to-land"  instruction 
under  current  day  practices  and  in  visual  conditions  appears  to  occur  over  a  wide 
range  of  time  intervals.     In  some  cases  the  aircraft  is  at  the  middle  marker  while 
in  others  it  might  be  2  miles  to  3  miles  out.     If  the  Local  Controller  does  not  have 
the  aircraft  in  sight  by  the  time  it  is  close  to  the  missed  approach  point,  the  Con- 
troller must  issue  missed  approach  instructions  unless  the  pilot  has  reported  that 
the  runway  lights  are  in  sight.     In  any  case,  the  termination  of  an  approach  by  the 
issuance  of  the  "clear  to  land"  message  cannot  take  place  any  later  than  when  the 
aircraft  is  at  the  middle  marker  or  the  missed  approach  point.     During  the  Land- 
ing Control  function,   conflict  checks  must  be  made  on  a  single  runway  basis  (see 
Function  K-5),   as  well  as  possible  conflicts  arising  due  to  usage  of  intersecting 
runways  (see  Function  L-3). 

No  special  sensor  requirements  have  been  established  for  Landing  Con- 
trol except  those  dictated  by  the  two  conflict  management  functions  K  and  L.     Air- 
craft location  at  the  middle  marker  will,  of  course,  terminate  the  time  at  which 
Landing  Control  can  be  exercised.    However,  during  the  last  20  seconds  to  30  sec- 
onds of  the  pre-touchdown  phase  of  the  arrival  aircraft,   it  is  anticipated  that  the 
conflict  management  jobs  performed  on  the  computer  may  still  be  in  process  so 
that  special  instructions  may  be  given  to  other  aircraft  on  the  surface  if  necessary. 

5.  2.  3.  9        Handoff  to  Ground  Control  (Function  H) 

Landing  aircraft  may  occupy  a  runway  from  periods  of  between  40  sec- 
onds and  perhaps  60  seconds.    Were  it  not  for  the  scheduling  and  conflict  manage- 
ment of  other  aircraft  the  handoff  process  to  the  Ground  Controller  could  take  place 
any  time  during  the  period  that  the  aircraft  is  decelerating  on  the  runway.     In  prac- 
tice, however,  handoff  to  the  Ground  Controller  is  performed  at  a  time  close  to 
aircraft  turnoff  from  the  runway.     The  Local  Controller  in  many  cases  recognizes 
A/C  Heading  Change  and  gives  an  anticipatory  "handoff". 


The  sensor  requirements,  therefore,   for  the  handoff  process  are  pri- 
marily those  established  for  conflict  management  purposes  to  be  certain  that  the 
runway  is  indeed  clear  for  other  operations.     Estimates  of  the  performance  re- 
quirements for  this  function  are  set  forth  under  the  conflict  management  functions 
K  and  L,   discussed  later. 

5.  2.  3.  10      Runway  Status  Monitoring  (Function  J) 

The  function  of  this  computer  job  is  primarily  one  of  providing  inputs 
to  the  conflict  management  functions  K  and  L.    However,  it  is  also  required  to 
provide  inputs  to  GCS  Conflict  Management  (H-2).    In  order  for  the  ground  control- 
ler to  release  a  departure  to  cross  an  arrival  runway  there  should  be  sufficient 
time  for  the  crossing  aircraft  to  clear  the  runway  before  the  next  arrival  approaches 
the  crossing  intersection.    The  time  elements  for  crossing  are  estimated  as  follows: 

Duration  (Sec) 

Communication  to  Pilot  5-7 

Pilot  Reaction  Time  0.  8 

Runway  Crossing  Time*  20-40 

Totals  25.8-47.8 

If  the  taxiway  crossing  point  is  at  the  mid-rollout  point  (i.e. ,  about 
20  seconds  after  the  arrival  crosses  the  threshold)  and  20  seconds  of  safety  buffer 
is  allowed  between  the  crossing  aircrafts  clearing  and  the  arrivals  reaching  the 
intersection,  a  crossing  should  be  withheld  if  an  arrival  is  within  50  seconds  of  the 
threshold.    Allowing  5-10  seconds  latitude  in  the  decision  making,  the  predicted- 
time -over- threshold  should  be  available  60  seconds  out  from  threshold.    At 
appraoch  speeds  of  up  to  150  knots  the  GCS  coverage  of  2.5N  miles  from  threshold 
is  established. 


*Reexamination  of  the  data  collected  at  O'Hare  indicated  a  mean  of  30  seconds 
with  a  standard  deviation  of  6  seconds.    The  range  of  values  was  from  18  seconds 
to  38  seconds. 


5.  2.  3.  11       Single  Runway  Conflict  Management  (Function  K) 

Operations  conducted  on  a  single  runway  make  it  necessary  for  the 
Local  Controller  to  evaluate  five  types  of  conflicts  on  a  regular  basis.  These  five 
conflicts  are  listed  in  Table  5-3  which  also  provides  an  indication  of  which  aircraft 
will  normally  be  given  priority  (A/C  #1)  as  well  as  a  qualitative  estimate  of  the  in- 
formation needed  by  the  Controller  for  decision-making  purposes.  The  three  main 
decisions  made  by  the  Controller  under  normal  conditions  are: 

For  Departures 

Clear  to  enter  runway  -  part  of  Function  A 

Clear  for  takeoff  -  part  of  Function  B 

For  Arrivals 


Clear  to  land  -  part  of  Function  G 

Accomplishment  of  these  decisions  in  an  optimum  manner  requires  in- 
formation on  both  surface  as  well  as  airborne  aircraft.  Each  of  the  five  conflicts 
will  be  discussed  in  detail  below. 

1.      Conflict  K-l  R/W  Entrance  Delay/Next  Arrival 

In  order  for  the  Local  Controller  to  release  a  Departure  from  the 
Local  Control  Departure  Q  onto  the  runway  there  should  be  sufficient  time  for  the 
outgoing  aircraft  to  be  clear  of  the  runway  ("OFF")  before  touchdown  of  the  next 
Arrival.    The  time  elements  involved  are  estimated  as  follows: 

Duration  (Sec. ) 
Communication  to  Pilot  5-7 

Pilot  Reaction  Time  0.  8 

A/C  Movement  Time  (to  R/W)  25-35 
Communication  to  Pilot  (Clear  to  R/W)  5-7 

Pilot  Reaction  Time  0.  8 

Start-to-Roll/"OFF"  Interval  30-50 

Total  67.6-101.6 
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Rounding  off  these  values  we  may  estimate  that  between  70  seconds  and 
100  seconds  are  needed  with  the  present  voice  system;  this  possibly  could  be  re- 
duced by  10  seconds  if  a  "signaling"  approach  (red/green  light)  was  employed. 

If  "t  "  is  the  predicted  "Time  over  R/W  Threshold"  for  the  Arrival 


It  has  been  estimated*  that  the  ability  of  a  pilot  to  control  his  speed 
from  the  Outer  Marker  to  Threshold  is  such  that  the  standard  deviation  of  his  time 
over  threshold  is  about  5  seconds.     If  this  value  is  also  used  for  a  (t  )and  the  upper 
value  of  100  seconds  is  selected  from  the  above  relationship,  then 

t    > 110  seconds 
P 

Since  landing  speeds  of  aircraft  range  from  100  knots  to  150  knots 

(167  fps  to  250  fps)  the  arrival  aircraft  must  be  no  less  than  18,  370  (110  x  167)  or 

27,500  (110  x  250)  feet  from  threshold  for  these  two  speeds  (three  nmi  to  five  nmi 

out).    This  essentially  defines  the  required  coverage  area  for  prediction  of  "time 

over  threshold". 

Using  the  prediction  accuracy  formulas  of  Appendix  E,  we  have 

at     =  --  cr  due  to  position  error 

1      v      A 
a 
at     =  t     —  due  to  velocity  error 

where  these  are  the  two  components  of  a  (t  )  and  it  is  assumed  that  no  appreciable 
braking  or  acceleration  takes  place  during  the  last  80  seconds  to  100  seconds  be- 
fore threshold  crossing.     If  a     is  taken  as  one  second  then,   for  the  slowest  air- 

h 

craft,  we  have  a    =  167  ft.     Taking  cr     =5  seconds  and  t  =  100  seconds  the  re- 
x  t2 

quired  velocity  accuracy  is  a     =  5(167)/l00  =  8.  3  fps. 


*Astholz,   et  al.  ,   "Increasing  Runway  Capacity",   Proceedings  of  IEEE,   March  1970 


2.    Conflict  K-2  Takeoff  Delay  due  to  Previous  Departure 

Since  R/W  occupancy  time  for  a  departure  will  range  from  20  seconds 
to  56  seconds,   and  the  time  required  to  move  a  Departure  from  the  LC  Departure 
Q  to  the  takeoff  point  averages  33  seconds  (range  12  seconds  to  73  seconds)  (see 
time  estimates  in  Table  5-1)  it  is  expected  that  "rolling"  departures  will  cause 
takeoff  delays  until  the  first  aircraft  is  clear  ("OFF")  of  the  runway.     An  indica- 
tion of  this  status  can  be  obtained  by  a  pilot  report.     Measurement  of  this  change 
in  aircraft  status  appears  difficult  to  accomplish.    On  the  other  hand,  prediction 
of  "OFF"  time  based  on  aircraft  velocity  and  possibly  acceleration  measurements 
while  on  the  runway  may  be  desirable.    Assuming  that  the  second  departure  can  be 
cleared-for-takeoff  no  sooner  than  6  seconds  to  8  seconds  before  the  first  aircraft 
is  actually  "OFF",  the  prediction  interval  of  interest  is  of  the  order  of  10  seconds. 
Ignoring  for  the  moment  wind  effects  (which  will  be  minimal  in  most  low  visibility 
conditions),  the  requirement  becomes  one  of  prediction  of  the  time  at  which  normal 
takeoff  velocity  is  reached.     Since 

t  =  —  for  linear  acceleration 

a 

we  may  define  the  two  components  of  prediction  error  (due  to  velocity  and  acceler- 
ation errors)  in  the  same  manner  as  for  the  position/velocity  relationship  t  =  — . 
This,   of  course,  assumes  independent  Gaussian  processes  for  "a"  and  "v".    The 
two  components  of  error  are 


Values  of  a     and  o      equal  or  less  than  1  second  appear  desirable. 

With  a  =  16  fps    (0.  5g)  a  value  of  o    =  10  fps  would  result  in  cr     =  0.  8  second. 

V  2 

Acceleration  measurement  uncertainty  of  1.  6  fps     (o  )  would  result  in  a      =  1 

A  n     -i      c\  ^ 

second  ( —  J  at  the  10-second  prediction  interval.     This  prediction  capability 

could  result  in  perhaps  6  seconds  to  8  seconds  time  saving  for  departures.     The 
impact  of  aircraft  equipment  type  on  the  variations  in  takeoff  characteristics  need 
further  investigation. 
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3.  Conflict  K-3  Takeoff  Delay/Wake  Turbulence 

Separation  between  departures  must  consider  wake  turbulence  effects 
due  to  "heavy"  aircraft.  Wake  turbulence  measurement  sensors  can  plan  a  signifi- 
cant role,  it  is  believed,  in  reducing  departure  delays  due  to  this  phenomena.  No 
special  requirements  on  the  aircraft  position,  velocity,  or  acceleration  sensors  can 
be  defined  at  this  time.  While  wake  formation  may  possibly  be  correlated  with  air- 
craft equipment  type  and  velocity,  wake  dissipation  takes  many  seconds  and  may 
not  be  readily  predictable.  Data  from  wake  turbulence  sensors  should  be  integrated 
into  the  Local  Control  System  for  use  in  this  function. 

4.  Conflict  K-4  Takeoff  Delay/Previous  Arrival 

Immediately  after  an  Arrival  has  crossed  the  runway  threshold,  the 
controller  can  perform  Function  A  (release  of  aircraft  from  Local  Control  Depar- 
ture Q  to  runway).    Runway  occupancy  time  by  Arrivals  is  longer  than  that  of  De- 
partures and  ranges  from  about  38  seconds  to  52  seconds  at  O'Hare  except  when 
aircraft  use  the  R/W  for  taxiing  (R/W  22 L).     Under  present  procedures  Departures 
are  not  cleared  for  takeoff  until  the  Arrival  is  clear  (or  almost  clear)  of  the  run- 
way; the  Controller  in  visual  conditions  does  give  anticipatory  clearances.     Ideally, 
a  "runway  available"  signal  to  the  Controller  perhaps  6  seconds  to  10  seconds  prior 
to  the  Arrival  being  actually  clear  of  the  runway  appears  desirable  to  reduce  depar- 
ture delays.    Relaxation  of  the  rule  that  only  one  aircraft  can  be  moving  on  the  run- 
way at  any  instant  of  time  could  increase  this  interval  to  perhaps  10  seconds  to  15 
seconds  since  the  minimum  total  time  from  release  to  takeoff  will  be  of  the  order 
of  40  seconds.     Prediction  of  the  aircraft  turnoff  maneuver  of  the  Arrival  could 
perhaps  be  accomplished  by  recognition  of  change  in  aircraft  heading  in  many  cases. 
For  low  angle  turnoffs  (where  the  angle  is  perhaps  30  degrees)  a  standard  deviation 
of  heading  change  of  perhaps  5  degrees  to  10  degrees  (o   )  is  believed  to  be  desirable. 

This  "Turn  Recognition"  process  wherein 

Q=  tan      - 


x  =  Position  component  orthogonal  to  runway 
y  =  Position  component  along  runway 

will  be  influenced  by  the  statistical  characteristics  of  the  sensor  geometry  with 
respect  to  the  runway  as  well  as  the  turnoff  geometry.  Additional  study  and/or 
simulation  will  be  required  to  ascertain  the  ability  to  recognize  "turns"  with  a 
minimum  of  time  delay. 

At  this  time  the  safer  criteria  appears  to  be  one  of  recognizing  aircraft 
occupancy  of  the  turnoff  link  (and  clear  of  runway);  i.e. ,  Link  Occupancy  plus 
Movement  Detection.    The  latter  process  is  desirable  since  the  turnoff  links  are 
short  and,  unless  the  aircraft  is  detected  as  "moving",  the  system  cannot  be  sure 
that  the  arrival  aircraft  is  completely  clear  of  the  runway.     It  should  be  recognized, 
however,  that  this  criteria  will  hamper  overall  response  time. 

5.    Conflict  K-5  Arrival  with  Previous  Operation 

The  preceding  four  conflicts,    K-l  through  K-4,  have  dealt  with  delays 
to  Departures.     Under  conflict  K-5  we  shall  consider  the  possible  impact  of  the 
preceding  operation  on  an  incoming  Arrival.    While  under  most  circumstances  the 
incoming  Arrival  must  be  given  priority,  there  may  be  situations  where  "permis- 
sion to  land"  should  be  denied. 

Three  situations  will  be  examined  under  this  conflict.     In  the  first,  a 
conflict  may  exist  between  an  Arrival  and  a  Departure  at  the  runway  start  point  but 
not  moving.     This  has  been  observed  in  the  data  collection  effort.     In  this  case,  the 
Departure  was  instructed  to  continue  across  the  runway  to  clear  the  threshold  for 
the  Arrival.     The  information  needed  by  the  Local  Controller  is  the  Predicted  Time 
over  Threshold  for  the  Arrival  while  for  the  Departure  aircraft  he  needs  heading 
information,   i.  e.  ,  is  the  Departure  pointed  along  the  runway  or  can  it  quickly 
"exit"  the  runway  if  necessary.    This  latter  option  is  not  possible  at  all  takeoff 
points,   i.  e. ,   it  can  be  done  on  27L  and  32R,   for  example,  but  not  on  32L  and  9R 


unless  the  aircraft  is  moved  onto  the  grass.  *      The  information  needed  by  the  con- 
troller is  the  "Predicted  Time  over  Threshold"  (for  the  Arrival)  similar  to  that 
needed  for  Conflict  K-l,   except  that  the  prediction  interval  will  probably  be  of  the 
order  of  50  seconds  to  70  seconds  rather  than  the  higher  values  required  in  K-l. 
We  shall  use  the  same  position  and  velocity  accuracy  estimates  for  this  conflict  as 
in  K-l,  recognizing  that  somewhat  better  prediction  capabilities  will  be  achieved. 
The  information  required  on  the  other  aircraft  is  its  relative  heading  with  respect 
to  the  runway  and  that  a  potential  runway  exit  is  available.     This  requirement 
appears  to  imply  "Turn  Recognition"  capabilities  when  the  aircraft  moves  out  onto 
the  runway. 

In  the  other  two  examples  of  K-5  wherein  a  "rolling"  Departure  or  Ar- 
rival is  on  the  runway  with  an  Airborne  Arrival  near  the  Missed  Approach  Point 
(MAP)  it  is  believed  that  the  former  cannot  take  place  unless  the  Departure  aborts 
its  takeoff  (see  Note  2  on  Table  5-3).    When  the  previous  Arrival  is  slow  in  clear- 
ing the  runway  it  may  be  necessary  to  issue  a  Missed  Approach  instruction  to  the 
incoming  Arrival  or  to  inform  it  to  "hold  short"  of  a  particular  point  on  the  runway. 
It  is  recognized  that  priority  should  be  given  to  the  airborne  Arrival;  however,   in 
certain  situations  this  may  be  impossible.     "Predicted  Time  over  Threshold"  is 
required  data  for  the  airborne  Arrival;  for  the  "rolling"  Arrival  on  the  runway  it 
is  desired  to  have  a  "Turnoff  Recognition"  or  prediction  as  soon  as  possible. 

5.  2.  3.  12      Intersecting  Runway  Conflict  Management  (Function  L) 

Most  operations  conducted  at  O'Hare  use  intersecting  runway  configur- 
ations.    The  location  of  the  intersection  of  the  runways  with  respect  to  the  thresh- 
old for  Arrivals  and  the  start  of  takeoff  point  for  Departures  is  a  major  factor  in 
the  decision  process  performed  by  the  Local  Controller.     Figure  5-6  illustrates 
four  types  of  intersections  based  upon  Arrivals  on  one  runway  and  Departures  on 
the  other.     These  four  cases  (Case  I  through  IV)  are  identified  as  Near/Near; 
Near/Far;  Far/Near;  and  Far/Far  with  the  first  designation  indicating  the  Arrival 
runway  and  the  second  the  Departure  runway. 


*The  control  flexibility  offered  by  this  pavement  design  at  the  runway  ends  appears 
to  be  a  desirable  feature  for  incorporation  in  future  runway  designs. 
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b)     Near  -  Far     R/W  Configuration 


c)   Far-  Near     R/W    Configuration 
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d)    Far -Far    R/W    Configuration 
Figure  5-6.    Intersecting  Runway  Configurations 


Three  types  of  potential  conflicts  have  been  identified  as  shown  in  Table 
5-4  for  operations  on  intersecting  runways.     In  the  first,   L-l,   a  Departure  on  one 
runway  must  be  released  so  as  to  avoid  a  conflict  with  either  an  incoming  airborne 
Arrival  or  an  Arrival  rolling  on  the  runway  but  not  yet  past  the  intersection.     In  the 
second  case,   L-2,  the  Departure  must  avoid  a  conflict  with  a  "rolling"  Departure 
(on  the  other  runway)  which  is  not  yet  past  the  intersection  (wake  turbulence  may 
also  be  a  factor  in  this  situation).     These  two  conflicts  (L-l  and  L-2)  represent 
"Takeoff  Delays"  which  can  be  minimized  by  the  use  of  prediction  or  estimation 
techniques  for  establishing  the  time  availability  of  the  intersection  (or  crossing). 
We  shall  use  the  term  "predicted"  to  indicate  the  estimated  time  that  an  airborne 
aircraft  will  reach  a  particular  crossing  while  the  term  "Estimated  Crossing  Time" 
will  be  applied  to  aircraft  (either  Arrivals  or  Departures)  which  are  "down"  on  the 
runway. 

The  third  type  of  conflict,   L-3,   is  that  occurring  between  two  moving 
aircraft  and  as  such  represents  the  most  stringent  safety  requirement.     In  the  first 
example  of  this  type  of  conflict  a  "rolling"  Departure,   because  of  delay  in  starting 
to  roll,  may  be  in  conflict  with  an  incoming  Arrival  beyond  the  MAP.     The  priority 
aircraft  in  this  case  is  probably  the  Departure.     The  Near/Far  Configuration  (Case 
II)  is  the  most  stringent  situation.     Information  on  the  Estimated  Crossing  Time 
(of  the  rolling  Departure)  can  permit  the  acceptance  or  rejection  of  the  incoming 
Arrival.     Another  example  of  the  L-3  conflict  would  be  between  an  airborne  Arrival 
and  a  "rolling  Arrival"  on  another  runway  which  has  not  yet  reached  the  Crossing. 
Here  the  Airborne  A/C  has  priority  and  the  other  aircraft  must  be  given  a  "stop" 
instruction  rapidly.     This  situation  is  most  likely  under  the  Near/Far  or  Far/Near 
runway  configurations.     The  data  needed  by  the  Controller  is  the  Estimated  Cross- 
ing Time  of  the  ground  Arrival  as  well  as  the  Predicted  Time  at  Crossing  for  the 
airborne  aircraft. 

From  the  above  discussion  it  can  be  seen  that  three  types  of  data  are 
required  for  either  control  of  the  runway  crossing  or  release  of  Departures.     These 
are: 
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1.  Predicted  Time  at  Crossing  -  of  Airborne  Arrivals 

2.  Estimated  Crossing  Time  -  for  "Rolling"  Departures 

3.  Estimated  Crossing  Time  -  for  "Braking"  Arrivals 

Since  the  prediction  interval  for  the  first  data  item  above  is  expected 
to  be  no  more  than  60  seconds,  the  required  position  and  velocity  accuracy  can  be 
satisfied  by  the  criteria  established  under  Function  K.     The  performance 
requirements  for  the  second  data  item  above  can  be  satisfied  with  the  criteria  estab- 
lished under  Function  K-5. 

The  third  data  item,   i.  e.  ,  the  Estimated  crossing  time  of  a  "braking" 
Arrival  at  a  future  intersection  is  needed  not  only  for  Function  L-3  at  intersection 
of  runways  but  also  needed  for  input  to  the  runway  Crossing  Control  function  per- 
formed by  the  Ground  Control  System.     Based  upon  measurement  of  the  position 
and  velocity  of  the  "braking"  Arrival,   several  estimates  can  be  made.     For  a  slow 
moving  Arrival,  an  estimate  based  on  the  assumption  that  no  acceleration  takes 
place  in  the  future  can  be  made  of  the  minimum  time  at  which  the  Arrival  will  reach 
the  intersection.     If  this  time  is  more  than    say  20  seconds  to  30  seconds,   then 
there  is  sufficient  time  to  stop  the  Arrival  if  necessary.     Fast  moving  Arrivals, 
say  at  60  knots  (about  100  fps)  or  that  are  within  1000  feet  of  the  intersection, 
probably  must  be  considered  as  positive  users  of  the  upcoming  intersection.     The 
estimate  of  time  past  the  intersection,   or  Estimated  Crossing  Time,   in  this  case 
must  be  delayed  until  the  Time-to-Go  of  the  Arrival  is  perhaps  10  seconds  or  less. 

5.  2.  4  Operational  Requirements 

The  operational  requirements  for  the  Local  Control  System  will  be 
specified  in  terms  of  the  responsibilities  of  a  single  Local  Controller  recognizing 
that  at  O'Hare  for  example  there  are  essentially  two  almost  independent  sets  of 
runways.     Of  primary  interest  is  the  maximum  traffic  that  a  single  Local  Control- 
ler will  handle  both  during  the  "busy"  hour  as  well  as  during  the  short  term  (3- 
minute  to  5-minute) peaks.     This  traffic  load  will  be  dependent  upon  runway  con- 
figuration.    For  a  single  runway  serving  just  arrivals  it  is  estimated  that  four 


aircraft  could  be  simultaneously  under  control,  three  airborne  (OM,   OM-MM, 
near  threshold),  and  one  on  the  ground  near  turnoff.    A  separation  value  of  2  nmi 
has  been  used  as  an  estimate  of  possible  future  standards.     Similarly  there  may 
be  four  simultaneous  departures  for  a  single  runway,   one  entering  the  runway,  one 
"rolling",  and  two  airborne  (prior  to  handoff).     From  these  estimates  and  the  fact 
that  2-3  runways  may  be  active  at  one  time  we  can  estimate  the  number  of  simul- 
taneous operations  in  progress.    This  represents  a  short  term  peak  load. 

While  the  present  hourly  quota  system  of  135  A/C  for  O'Hare  implies 
about  70  ope  rat  ions /hour  for  each  side  of  the  airport,  the  tower  is  currently  (sum- 
mer 1974)  handling  from  140-170  ops/hr.     It  is  recommended  that  the  LCS  be  sized 
to  handle  100  ops/hr  per  Local  Controller.    We  may  summarize  the  traffic  load  as 
follows: 

Number  of  Active  Runways  3 

Number  of  Simultaneous  A/C  under  Control  10-12 

Busy  Hour    Ops  Rate  (Future)  100/hr 

The  LCS  must  be  capable  of  operating  in  a  variety  of  runway  configura- 
tions.    Mixed  operations  on  each  of  the  three  active  runways  must  be  achievable. 
In  addition  the  system  must  be  capable  of  handling  a  variety  of  crossing-runway 
situations. 

5.  3  PRELIMINARY  MODULE  DESCRIPTION 

5.  3.  1  Overall  Characteristics 

The  major  components  of  the  proposed  semi-automated  LCS  are  Sur- 
veillance Sensors,   Data  Processor,   and  Displays  plus  Input/Output  devices.    These 
components  must  be  connected  via  dedicated  communication  facilities  of  either  a 
"hardwire"  and/or  radio  nature.     Independent  displays  are  provided  for  the  two 
Local  Controllers.    The  set  of  surveillance  sensors  may  or  may  not  be  geographi- 
cally independent.    This  gross  representation  of  the  total  LCS  does  not  imply  that 
some  pre-processing  of  surveillance  data  cannot  be  done  in  the  sensors  themselves. 


While  the  description  of  the  LCS  has  been  based  on  the  use  of  a  single 
data  processor,  integration  of  this  system  with  a  similar  Ground  Control  System 
might  result  in  a  single  processor  for  use  by  both  systems. 

Three  types  of  surveillance  sensors  have  been  shown  feeding  into  the 
data  processor.     The  first  type  of  sensor  would  be  one  wherein  aircraft  in  the 
ground  environment  are  kept  under  surveillance;  the  second  would  be    devoted  toward 
surveillance  of  airborne  aircraft  on  both  the  approach  and  departure  flight  paths; 
the  third  sensor  would  be  used  for  determination  of  "runway  occupancy"  checks  on 
non-cooperating  vehicles.    While  three  independent  sensor  systems  have  been  shown, 
it  may  be  possible  for  one  sensor  system  to  perform  the  three  types  of  surveillance 
functions  illustrated  in  Figure  5-7. 

It  is  anticipated  that  the  data  processor  will  also  perform  scheduling 
functions  to  activate  on  the  displays  the  proper  information  for  the  specific  function 
to  be  performed  by  the  Local  Controller.     It  is  recognized  that  a  large  amount  of 
information  is  currently  acquired  by  the  Local  Controller  by  means  of  visual  sur- 
veillance techniques  over  a  large  area  of  coverage.     Condensation  of  this  informa- 
tion, as  well  as  proper  selection  of  the  data  elements,  will  be  a  prime  goal  in  the 
concept  development  of  the  displays.     It  is  envisioned  that  there  will  be  multiple 
displays/data  inputs  available  for  the  Controller  with  cueing  assistance  provided 
from  the  data  processing. 

5.  3.  2  Interface  Considerations 

The  LCS  must  interface  with  the  Ground  Control  System  as  well  as  the 
ARTS  system.     In  the  latter  area,   it  is  currently  envisioned  that  interface  will  be 
required  only  for  Arrival  aircraft  and  that  Departures  from  the  LCS  will  be  handled 
no  differently  than  the  acquisition  process  currently  performed  by  the  Departure 
Controller  in  the  TRACON.     On  the  other  hand,   arrival  information  from  the  ARTS 
data  base  will  serve  to  ease  the  acquisition  problem  for  the  airborne  surveillance 
sensors  and  also  provide  coarse  position  information  for  use  in  some  of  the  Local 
Control  System  functions  (for  example,  Spacing  Control). 
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The  LCS  must  supply  information  to  the  Ground  Control  System  for 
handoff  purposes  as  well  as  runway  occupancy  or  prediction  data  to  be  used  by  the 
Ground  Control  System  in  performing  the  Runway  Crossing  control  function.     In  the 
latter  area,   conversely,   it  is  expected  that  the  GCS  will  provide  information  on 
taxiing  aircraft  that  might  impact  upon  the  operations  of  the  runways.     Aircraft 
that  have  been  handed  off  by  the  Ground  Control  System  to  Local  Control  automat- 
ically will  be  entered  in  the  Local  Control  System  data  processor  at  the  time  this 
event  occurs.     These  departure  aircraft  essentially  will  be  in  an  inactive  status  as 
they  move  toward  the  top  of  the  Local  Control  departure  queue. 

The  block  diagram  of  the  LCS  also  shows  possible  alternate  communi- 
cation paths  between  the  Controller  and  aircraft;  these  paths  are  of  a  signaling 
nature  and  would  be  via  control  lights  for  such  diverse  purposes  as  releasing  air- 
craft onto  the  runway  entrance,   clearing  aircraft  for  takeoff,  etc. 

Additional  interface  requirement  between  LCS  and  other  portions  of  the 
ATC  system  will  necessitate  the  inputting  of  support  data  to  the  LCS  data  processor. 
This  may  include  such  parameters  as  the  runway  configuration  in  use,   inputs  from 
wake  turbulence  detector  sensors,  weather  data,  etc. 

5.  4  BENEFITS  ANALYSIS 

5.4.1  Capacity  Improvement  and  Delay  Reduction 

While  the  present  quota  system  at  O'Hare  is  135  ops/hr.  ,  there  are 
numerous  occasions  when  the  ATCT  will  handle  between  140-170  aircraft.     These 
peak  hourly  loads  are  most  prevalent  in  the  summer  period;  the  busiest  hour  at 
O'Hare  was  208  aircraft  moved  in  1968.    Weather  is  the  primary  cause  of  long  de- 
lays.    Such  factors  as  local  thunder  storms  forcing  larger  separations  as  well  as 
conditions  of  poor  visibility  represent  two  different  weather  conditions  affecting 
operations.     In  good  weather,   airport  operational  levels  of  120-140  aircraft/hour 
result  in  average  delay  per  departure  between  6.  2  minutes  to  8.  5  minutes.     These 
results  are  for  periods  when  essentially  "no  delay"  would  be  reported  by  the  ATCT. 
These  delays  have  been  found  to  be  sensitive  to  the  active  runway  configuration.     It 
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is  believed  that  other  factors  such  as  individual  differences  between  controllers 
may  also  play  an  important  role  in  these  delay  variations. 

The  data  inputs  to  the  Local  Controller  come  either  from  the  position 
information  on  the  BRITE  (Airborne  Arrivals  only)  or  from  visual  surveillance. 
These  limited  data  inputs  do  not  provide  much  prediction  capability  for  decision- 
making purposes  by  the  Controller.     It  is  in  this  area  that  the  proposed  semi- 
automated  LCS  can  provide  substantial  assistance  to  the  functional  activities  of  the 
Local  Controller. 

This  assistance  would  take  the  form  of  providing  "flags"  or  signals  to 
the  Controller  as  to  the  acceptability  of  a  particular  decision  (Clear  to  Takeoff; 
Clear  to  Enter  Runway,  etc)  as  well  as  furnishing  "scheduling"  recommendations. 
The  benefits  from  the  LCS  would  consist  of  improvements  in 

Arrival/Departure  Sequencing 

Landing  Control 

Runway /Runway  Crossing  Control 

Interfacing  with  Ground  Control  for 

•  Taxiway/runway  Crossing  Control  and 

•  Indication  of  when  Turnoff- Generated  Conflicts  can  exist 

These  improvements  should  reduce  good  weather  delays  and  signifi- 
cantly increase  the  airport  operational  levels  under  conditions  of  poor  visibility 
when  it  normally  falls  between  10  percent  and  25  percent  of  normal  operations. 

If  a  reduction  of  2  minutes  could  be  achieved  in  the  departure  delays 
in  good  weather  conditions  this  would  result  in  a  daily  saving  of  about  700  x  2  = 
1400  minutes  based  upon  700  departures  taking  place  during  busy  hours.    Over  the 
year  this  translates  into  cost  savings  (at  $11.  23/minute)  of  $4.  7  million  (1400  x 
300  x  11.23). 


5.4.2  Safety  Benefits 

The  proposed  LCS  can  provide  substantial  safety  benefits  by  performing 
many  "housekeeping"  and  estimations  functions  for  the  Local  Controller,  thereby 
releasing  additional  time  for  the  exercise  of  human  judgment.     Such  safety  benefits 
become  of  greater  significance  in  periods  of  low  visibility  if  reasonable  operational 
levels  are  to  be  achieved  in  these  periods. 

The  operational  areas  wherein  safety  will  be  improved  have  been  de- 
scribed earlier  in  this  section  as  well  as  in  the  discussion  on  the  Conflict  Manage- 
ment function.  Provision  of  additional  information  on  operations  in  these  areas  on 
a  timely  basis  (when  needed)  can  also  minimize  differences  between  controller  de- 
cisions and  task  scheduling.  These  factors  should  further  reduce  safety  incidents 
in  the  most  vulnerable  portion  of  the  tower  operations,   i.  e.  ,   Local  Control. 

5.  4.  3  Workload  Reduction 

The  workload  of  the  Local  Controller  can  be  only  partially  estimated 
from  the  communication  traffic.    When  delays  exist  the  Controller  must  in  most 
cases  wait;  during  this  interval  he  is  continually  reevaluating  the  situation.     Table 
5-5  provides  an  estimate  of  the  functional  activity  of  a  Local  Controller  for  depar- 
tures (represented  by  "d")  and  Arrivals  (represented  by  "a")  under  the  present 
system  as  well  as  in  the  proposed  semi-automated  real  time  control  system.     It  is 
estimated  that  appreciably  more  effort  is  necessary  for  Departures  than  Arrivals 
under  the  current  system.     Using  the  values  shown  of  8d  and  (5.  5-7)a  given  in  this 
table,   an  operations  rate  of  60/hr  would  require  the  performance  of  405-450  func- 
tions per  hour.     In  a  peak  minute  perhaps  10-12  functions  would  require  service. 
This  functional  load  does  not  appear  tractable  by  a  single  individual.     The  Control- 
ler therefore  adapts  to  the  situation  (estimates  Spacing  Control,  performs  less 
monitoring  of  Departure  Routing,   and  maintains  further  separation  to  ensure  no 
possible  conflicts  can  occur).     Under  the  semi-automated  concept,  the  functional 
activity  level  can  be  substantially  reduced,  primarily  since  the  computer  will  be 
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performing  the  calculation  of  "release"  times,  detecting  potential  conflicts,  and 
providing  spacing  control  assistance  to  the  Controller.     The  application  of  "signal- 
ing" for  Departures  (release  onto  runway,  release  for  takeoff)  is  also  a  significant 
possible  source  of  workload  reduction. 

With  the  LCS,  therefore,  it  is  estimated  that  the  Controller's  workload 
would  be  reduced  to  between  50  percent  to  60  percent  of  the  present  workload  (on  a 
functional  basis). 


SECTION  6  -  RELATED  SUPPORT  CONCEPTS 

6.1  AUTOMATIC  GATE  STATUS  EQUIPMENT  (AGSE)  CONCEPT 

6.1.1  Introduction 

The  Automatic  Gate  Status  Equipment  (AGSE)  concept  is  relatively 
new  to  airport  surface  traffic  control.    The  AGSE  provides  a  means  of  coordi- 
nation between  the  ATCT  and  airlines  flight  operations  in  the  management  and 
control  of  aircraft  movements,  which  heretofore  has  not  existed. 

The  AGSE  concept  has  been  discussed  to  a  large  extent  in  Section  3 
as  an  integral  element  of  the  Ramp  Control  System  concept.    It  plays  an  im- 
portant role  in  the  Ramp  Control  System  for  the  implementation  of  Positive 
Ramp  Control  at  airports  requiring  this  capability.    However,  the  AGSE  con- 
cept can  be  quite  useful  at  those  airports  for  which  Positive  Ramp  Control  is 
not  required.    This  importance  derives  from  the  reduction  of  controller-pilot 
communications  workload  which  may  be  achieved. 

This  section  is  devoted  to  a  discussion  of  the  AGSE  concept  in  this 
latter  context.    Reference  to  previous  discussions  in  Section  3  will  be  made 
where  applicable  to  avoid  unnecessary  repetition. 

6.1.2  Information  Requirements  Estimation 

In  an  airport  environment  in  which  Positive  Ramp  Control  is  not 
required,  the  requirements  for  AGSE  stems  from  three  basic  information  needs 
of  aircraft  ground  control.    These  are: 

•  Identification  of  the  point  of  origination  (terminal  gate 

or  other  portion  of  the  airport  ramp  area)  for  departures 
and  other  flights  outbound  from  the  passenger  terminal(s). 

•  Identification  of  the  destination  (terminal  gate  or  other  por- 
tion of  the  airport  area)  for  arrivals  and  other  aircraft  in- 
bound to  the  passenger  terminal (s). 


•  Information  on  the  availability  of  the  destination  gate  for  ar- 
rivals and  the  extent  of  any  delay  in  its  availability. 

•  Information  that  the  arrival  aircraft  arrived  at  and  docked 
or  parked  at  their  destination  gate. 

Knowledge  of  the  point  of  origination  is  required  for  determination 
and  transmission  of  the  routing  of  the  departure  to  the  appropriate  departure 
runway  by  (Outbound)  Ground  Control.    The  second  data  element  is  needed  for 
determination  and  transmission  of  the  routing  for  other  outbound  flights  to  the 
appropriate  cargo /hangar  area  by  (Inbound)  Ground  Control.    The  third  is  de- 
termination of  the  position  of  the  flight  for  reference  in  sequencing  (control- 
ling) the  entry  of  the  flight  into  the  traffic  flow  on  the  taxiway  network.    The 
fourth  element  (position  of  the  flight)  would  be  useful  for  initiation  of  automatic 
surveillance  and  tracking  of  its  movements  in  order  to  reduce  the  time  for 
search  and  acquisition  by  the  surveillance  subsystem. 

Knowledge  of  the  aircraft  destination  is  similarly  important  for 
routing  of  Arrivals  or  other  traffic  to  the  terminal  building.    Depending  on  the 
airport  runway-taxiway  surfaces  configuration  and  associated  routing  patterns 
this  data  element  may  also  be  important  in  sequencing  of  these  flights  into  the 
traffic  flow  pattern. 

Availability  status  of  aircraft  destination  gates  is  also  important 
in  the  aircraft  routing.    When  a  flight's  gate  is  not  available  it  may  be  neces- 
sary to  route  it  to  a  holding  area  (e.g. ,  the  Penalty  Box  at  O'Hare).    In  addition, 
since  there  may  be  several  holding  areas,  the  usage  of  these  is  dependent  on 
the  destination  gate  of  the  flight  and/or  the  amount  of  gate  delay  anticipated. 
This,  therefore,  will  also  affect  the  routing  of  the  aircraft. 

Knowledge  that  aircraft  have  arrived  at  and  docked/parked  at  their 
destination  gate  is  important  for  two  reasons.    The  first  is  that  when  this  oc- 
curs the  aircraft  no  longer  represents  any  potential  need  for  service  by  the 
ATCT.    Under  certain  conditions  where  the  controller  cannot  visually  observe 


this  event,  explicit  action  to  indicate  its  occurrence  becomes  neceessary.    These 
conditions  could  exist  when  controller  visibility  of  the  terminal  ramps  is  blocked 
due  to  the  physical  configuration  of  the  terminal  or  other  physical  structure  with 
respect  to  the  location  of  the  ATCT.    They  could  also  exist  under  low  visibility 
operating  conditions. 

The  second  reason  is  that  aircraft  gate  arrival  data  is  a  useful  ele- 
ment in  maintaining  gate  availability  status.  This  could  eliminate  the  need  for 
direct  coordination  with  airline  flight  operations  for  each  arrival. 

6.1.3  Functional  Flow  Description 

The  functional  flow  of  the  AGSE  in  airports  not  requiring  Positive 
Ramp  Control  is  illustrated  in  Figure  6-1. 

As  in  the  previous  Ramp  Control  System  discussions  the  pre-filed 
gate  schedules  and  updates  by  airlines'  flight  operations  personnel  would  be 
maintained  in  the  Gate  Schedules  File.    This  information  would  be  utilized  in 
the  generation  of  improved  flight  strips  as  previously  discussed. 

When  an  arrival  flight  is  added  to  the  Ground  Control  Arrivals  Q 
List  by  the  Local  Control  System,  a  request  for  a  gate  availability  for  the 
flight  is  received.    The  Gate  Schedules  file  will  then  be  accessed  to  determine 
the  assigned  gate  and  its  availability.    A  gate  could  be  defined  as  available  if 
it  was  open  or  a  departure  on  the  gate  has  pushed  back  and  called  for  taxi. 

If  the  assigned  gate  is  found  to  be  available,  the  assigned  gate 
number  and  its  availability  would  be  transmitted  to  the  Ground  Control  System. 

If  the  assigned  gate  is  not  available  a  gate  verification  request  would 
be  displayed  to  the  appropriate  airline's  ramp  controller.    A  revised  gate  as- 
signment and/or  gate  availability  delay  would  be  entered  by  the  airline's  ramp 
controller.    This  data  would  be  transmitted  to  the  Ground  Control  System  and 
would  update  the   Gate  Schedules  data. 
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Figure  6-1.    Functional  Flow  for  AGSE  in  Airports  Without 
Positive  Ramp  Control 


At  a  later  time  the  flight's  arrival  at  its  gate  would  be  reported  by 
the  pilot  to  the  airline's  ramp  controller  (or  observed  by  the  ramp  controller, 
where  the  airline  operates  its  own  operations  tower).  This  status  report  would 
be  entered  by  the  airline's  ramp  controller.  This  would  result  in  transmission 
of  an  indication  of  gate  arrival  to  the  Ground  Control  System  in  order  that  the 
flight  could  be  deleted  from  the  Active  Aircraft  List.  It  would  also  update  the 
Gate  Schedules  data. 

6.1.4  Operational  Requirements 

The  AGSE  should  possess  sufficient  capacity  to  meet  the  require- 
ments for: 

•  Storage  of  Gate  Schedules  data 

•  Processing  of  all  inputs  updating  this  data  base 

•  Display  of  gate  availability  requests  at  all  airlines 
installations 

•  Receipt,  processing  and  transmission  of  response  to 
gate  availability  queries. 

•  Generation  and  transmission  of  gate  arrival  status  to 
Ground  Control  System. 

At  a  minimum,  sufficient  capacity  should  be  provided  to  meet  all 
requirements  at  the  peak  operations  rate  of  the  airport  to  avoid  any  delay  in 
the  receipt,  processing,  and  response  to  gate  availability  requests  from  the 
Ground  Control  System.    Under  low  visibility  operating  conditions  it  is  likely 
that  changes  to  gate  assignments  and/or  gate  availability  delays  would  increase. 
The  AGSE  should  possess  sufficient  capacity  to  handle  the  increased  number  of 
data  entries  and  display  of  gate  verification.    However,  as  the  volume  of  traf- 
fic operations  is  likely  to  be  lower  under  these  conditions  the  capacity  for  oper- 
ation at  the  peak  operations  rate  of  the  airport  may  be  sufficient. 


6.2  STANDARD  TAXIWAY  ROUTING  MODULE 

6.2.1  The  Routing  Communication  Problem 

Ground  control  procedures  at  O'Hare  require  that  the  Outbound 
Ground  issue  to  every  departing  aircraft  a  taxi  route  to  the  current  departure 
runway.    Presently,  this  routing  data  is  communicated  to  the  pilot  by  the  Out- 
bound Ground  Controller  as  part  of  Function  B  (Release  of  Departure  A/C  into 
the  taxi  system),  i.e.,  during  the  initial  taxi  clearance  instruction.    An  example 
might  be: 

"Eastern  114.  Your  runway  is  going  to  be  14  Right.  Turn 
right  onto  the  Outer  behind  that  DC  10  coming  from  your 
left.  Follow  to  the  New  Scenic  and  then  up  the  Bypass  to 
the  North  West  Parallel  taxiway." 

During  busy  traffic  hours,  communications  are  issued  from  Out- 
bound Ground  to  the  pilot  in  a  more  abbreviated  format.    This  format  permits 
the  controller  to  handle  more  aircraft  without  saturating  his  communication 
channel.    Thus  the  clearance  example  above  is  shortened  to: 

"Eastern  114,  14R,  Outer  behind  the  10  to  Scenic,  Bypass  to 
North  West  taxi" 

This  abbreviated  format  requires  greater  pilot  attention  ,  since 
there  are  fewer  redundant  words.    He  must  know  the  O'Hare  taxiway  layout 
better,  since  the  route  requires  greater  interpretation.    Finally,  the  rapid  mes- 
sage rate  can  increase  pilot  misunderstandings  of  the  selected  route  and  control 
instructions.    Not  all  misunderstandings  are  pilot  errors.    In  the  above  example, 
the  Northwest  taxiway  and  the  Northwest  Parallel  taxiway  are  at  opposite  ends 
of  O'Hare.    Should  the  pilot  take  the  "Old  Scenic"  instead  of  the  "New  Scenic" 
in  the  abbreviated  format  example,  runways  4L  and  9L  may  be  crossed  before 
the  Outbound  Ground  detects  the  error. 

A  similar  routing  scenario  occurs  with  arrival  aircraft  and  the  In- 
bound Ground  Controller.    Here  Inbound  Ground  must  issue  a  taxi  route  to  each 


arrival  aircraft.    This  routing  data  is  communicated  to  the  pilot  by  Inbound  Ground 
on  the  initial  communications  with  the  pilot  after  handoff  from  Local  Control  (at 
start  of  Function  E,  Acceptance  of  A/C  into  Taxi  System).    Again,  as  traffic 
increases,  Inbound  Ground  will  issue  route  and  control  instructions  in  an  abbre- 
viated format  in  order  to  prevent  saturating  his  communications  channel. 

Safety  incidents  can  occur  when  routing  misunderstandings  result 
in  aircraft  crossing  active  runways  or  competing  simultaneously  for  the  same 
piece  of  taxi  pavement.    The  Standard  Taxiway  Routing  module  (STR)  is  pro- 
posed to  reduced  this  safety  hazard  as  well  as  increase  the  Ground  Controller's  work- 
load capability  (number  of  aircraft  handled). 

6.2.2  Standard  Taxiway  Routing  Considerations 

At  O'Hare,  most  departure  taxi  routing  schemes  are  procedurally 
established  by  parameters  that  are  independent  of  Outbound  Ground  Controller 
actions.    These  parameters  such  as  gate  position,  departure  runway,  etc.  ,  are 
usually  fixed  and  known  well  ahead  of  taxi  clearance  time.  As  such,  detailed 
departure  routing  can  be  correctly  established,  for  most  aircraft,  minutes  be- 
fore taxi  clearance  requests  are  to  be  issued. 

Similarly,  arrival  aircraft  have  established  routing  parameters 
that  are  independent  of  Inbound  Ground  action.    Again,  these  parameters  such 
as  landing  runway  or  gate/penalty  box  destination  can  be  determined  well  ahead 
of  Local  Control  handoff.  Thus,  detailed  arrival  routing  can  also  be  established 
several  minutes  before  handoff. 

The  Standard  Taxiway  Routing  module  is  proposed  to  perform  the 
establishment  and  issuance  of  standard  taxi  routing  for  all  aircraft  entering 
the  taxiway  system.    These  are  the  five  steps  of  the  initial  routing  sequence 
outlined  in  Figure  6-2.    The  STR  module  will  eliminate  the  burden  of  detailed 
routing  responsibility  on  the  two  ground  controllers  and  their  communications 
channels.    Pilots  could  then  receive  their  routing  instructions  in  some  other 
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Figure  6-2.    Initial  Routing  Sequence  of  Inbound  and  Outbound  Ground 


manner  and  most  likely  prior  to  taxi  clearance  requests.    Using  STR,  the 
pilot  and  the  Ground  Controllers  will  both  know  the  detailed  routing  scheme  as- 
signed to  the  aircraft.    By  adding  a  phonetic  such  as,  "I've  got  STR  Alpha",  to 
the  initial  Step  1  call,  the  pilot  has  performed  Step  5,  confirmation  of  the  route. 
The  Ground  Controller  will  only  issue  changes  to  the  STR  route  (rare)  as  re- 
quired for  conflict  resolution  or  required  recent  changes  due  to  the  runway, 
taxiway,  or  terminal  traffic  control  configurations. 

6.2.3  STR  Module  Development  Concepts 

The  STR  module  will  develop  in  stages  from  an  initial  primitive 
form  until  it  is  finally  integrated  into  a  fully  automated  taxiway  routing  control 
system  of  later  years.    The  initial  stages  of  STR  may  be  implemented  with  just 
procedural  changes.    As  such,  the  STR  system  will  handle  the  bulk  of  the  pre- 
dictable routing  now  burdening  the  Inbound  and  Outbound  Ground  controllers. 
The  intent  is  to  offload  this  burden  onto  the  as  yet  unspecified  STR  techniques. 

Possible  methods  of  communicating  the  routing  information  to  the 
pilot  include 

1.  The  use  of  data  links. 

2.  Issuance  during  the  clearance  delivery  process.    This  may 
require  that  confirmation  of  enroute  clearance  is  handled 
in  a  different  manner  than  at  present. 

3.  Use  of  billboard  type  signs  at  the  gates. 

4.  ATIS  type  channels. 

The  STR  module  is  not  associated  with  a  specific  piece  of  develop- 
mental hardware,  but  is  part  of  the  taxiway  routing  function  (Function  H)  and 
can  be  implemented  by  various  methods.    As  the  developmental  hardware  items 
of  the  ASTC  modules  are  installed,  the  STR  module  may  be  implemented  with 
this  hardware  and  in  later  years  it  could  be  integrated  into  a  fully  automated 
taxiway  routing  control  system.    Various  stages  of  STR  implementation  will 
result. 


A  criteria  for  the  STR  module  design  is  to  maximize  payoff  in  terms 
of  increased  safety,  increased  aircraft  throughput  rates,  ability  to  operate  ef- 
fectively at  lower  weather  minimums,  and  reduced  controller  communications 
workloads.    Events  of  lower  probability,  such  as  "pop-ups"  or  Cat  IIIC  capabil- 
ity, may  be  excluded  from  STR  unless  their  payoffs  justify  the  increased  costs 
and  complexity.    It  may  be  that  some  STR  methods  cannot  implement  satisfactory 
taxi  routing  of  arrivals  since  arrival  routing  is  less  predictable.    For  instance, 
early  or  late  runway  turnoffs  of  arrival  may  result  in  different  standard  taxi 
routes.    Also,  a  gate  status  change  or  ramp  pushback  congestion  can  dynamically 
alter  arrival  routing. 

6.2.4  Functional  Requirements  Estimation 

The  following  is  an  estimate  of  the  functional  requirements  of  the 
Standard  Taxiway  Routing  Module.    As  indicated  in  the  previous   paragraph, 
STR  is  primarily  a  procedural  module  not  associated  with  a  specific  hardware 
item.    The  STR  module  is  part  of  the  taxiway  routing  function  that  deals  with 
the  issuance  of  standard  routes  to  all  aircraft  entering  the  taxiway  system.    Its 
elements  will  be  undergoing  change  as  hardware  is  added,  obsoleted  or  up- 
graded in  the  ASTC  systems.    Thus,  the  STR  module  requirements,  the  result- 
ing benefits,  and  actual  implementation  may  be  affected  by  each  change  in  the 
total  ASTC  system. 

The  functional  requirements  or  elements  of  the  STR  module  are 
tabulated  below  and  outlined  in  Figure  6-2. 

1.  Aircraft  Identity 

2.  Acquisition  of  Route  Selection  Parameters 

3.  Route  Selection  Algorithm 

4.  Route  Issuance 

5.  Pilot  Confirmation 


The  necessity  for  aircraft  identify  depends  on  the  particular  type  of 
STR  module.  The  ATIS  broadcast  type  of  STR  Module  would  not  require  initial 
aircraft  identity.    The  advanced  data  link  STR  module  would  require  aircraft 
identify  if  it  is  to  perform  individual  route  selection  and  issuance. 

The  Route  Selection  parameters  are  the  information  inputs  used  by 
Inbound  and  Outbound  Ground  Controllers  to  select  a  particular  taxiway  route 
for  arrivals  and  departures.    Table  6-1  lists  the  major  Route  Selection  param- 
eters used  by  the  O'Hare  Inbound  and  Outbound  Controllers  in  early  1974.    The 
list  changes  periodically  as  the  airport  layout  and  traffic  control  procedures  are 


Table  6-1.    Route  Selection  Parameters 


Routing 

Selection  Parameters 

Affected 

Controllers  Source 

Runway  Configuration  in  Use 

Both 

ATC,  local 

Taxiway  Configuration  (Mainte- 
nance/Obstructions) 

Both 

Visual,  radio,  other 

Surface  Origin  and  Destination 

Both 

Radio,  visual,  surveillance 
sensors 

Aircraft  Type  (747  Heavy) 

Both 

Part  of  A/C  identity 

Gate  Status 

Arrival 

Visual,  radio   from  Ramp 
Control  System 

Penalty  Box-Hold  Points  Status 

Arrival 

Visual,  other 

In  Trail  Restrictions* 

Departure 

Flight  strip 

First  Fix* 

Departure 

Flight  strip 

*May  impact  on  Surface  Origin  and  Destination. 


Eleven  major  runway  configurations  are  identified  in  the  Operation- 
al Analysis  report  for  O'Hare  in  1974.    Each  configuration  results  in  two  or 
more  standard  departure  routes  plus  alternates.    An  STR  functional  require- 
ment is  to  select  the  correct  routes  from  these  70  or  so  standard  routes.    The 
selection  process  or  algorithm  is  based  on  the  selection  parameters.    This  re- 
quirement can  be  a  simple  Flight  Data  Controller  Table  Look-up  procedure  or 
it  may  be  a  program  within  a  computerized  automated  routing  control  system. 

The  functional  requirement  for  route  issuance  will  be  the  STR  com- 
munication link  to  the  pilot.    At  present,  the  Ground  Controller  half  duplex  par- 
ty line  radio  channel  performs  this  function.    Any  effective  STR  module  will 
have  to  develop  a  different  link  or  method  of  communicating  detailed  routing 
to  the  pilots.    For  the  semi-automated  ASTC  system,  it  appears  that  VHF  radio- 
voice  communications  will  be  used  exclusively.    In  the  more  advanced  ASTC  sys- 
tems of  later  years,  STR  communications  may  be  assisted  by  automated  CGE 
and/or  VGE  systems.  As  an  example,  a  CGE  cockpit/ tower  data  link  with  au- 
tomatically switched  control  signs  and  lighting  systems  may  be  used  for  route 
issuance.    Costs  and  responsibilities  for  CGE  and  VGE  systems  will  spread 
across  the  airport  authority,  the  air  carriers,  and  the  FAA  causing  great  in- 
ertia on  speedy  implementation.    The  present  controller  partyline  single- 
channel  communications  may  be  unacceptable  for  STR  purposes  due  to  such 
hazards  as  a  "stuck-mike"  button  or  simultaneous  transmissions  by  two  or  more 
channel  users.    Discrete  address-handshaking  roles  over  a  multichannel  com- 
munication link  may  be  required  for  STR  communications. 

The  pilot  confirmation  of  the  route  is  considered  a  necessary  feed- 
back control  requirement.    Without  confirmation,  the  ground  controller  has  no 
positive  assurance  that  the  pilot  has  received  the  correct  route.    The  present 
use  of  partial  confirmation  is  hazardous.    Full  confirmation  by  the  pilot  re- 
porting back  the  detailed  route  may  be  necessary.    This  could  be  automated 
with  CGE  items  such  as  the  Cockpit- Tower  data  link,  but  would  saturate  the 
present  Ground  Controller  communication  channels. 


SECTION  7  -  SUMMARY  OF  SENSOR  PERFORMANCE  REQUIREMENTS 

This  section  summarizes  the  estimates  of  performance  requirements 
made  in  the  preceding  sections  of  this  report.  In  addition,  the  independent  esti- 
mates made  by  our  subcontractor,  Bendix,  are  also  discussed. 

If  the  Ramp  Control  System  option  is  selected,  it  is  recommended 
that  no  attempt  be  made  to  obtain  aircraft  maneuver  data  (position,  velocity,  etc. ) 
on  aircraft  within  the  ramp  area  except  for  automatic  transfer  of  VFRs  and  general 
aviation  IFRs  to  the  Handoff  to  Ground  Control  Departure  Q  function  (see  paragraph 
3.  2.  3. 1).    Such  automatic  transfer  will  require  resolution  capabilities  on  the  order 
of  100  feet  from  aircraft  center  to  aircraft  center.    In  general,  however,  informa- 
tion on  aircraft  position  within  the  ramp  area  will  be  obtained  via  procedures  using 
AGSE  (gate)  data,  estimates  made  from  empirical  data  (using  measured  values  of 
pushback  time,  entry  time,  etc.)  and  inputs  from  the  GCS. 

The  semi-automated  GCS  must  provide  surveillance  data  on  all  aircraft 
on  the  taxi  ways  and  runways  since  the  latter  are  sometimes  used  for  taxi  purposes 
when  they  are  not  in  use  for  landing  or  departing  aircraft.  Surveillance  data  is  not 
required  on  aircraft  entering  staging  areas  or  the  Local  Control  Departure  Q;  air- 
craft "track"  will  be  suspended  at  these  locations  and  reinstituted  at  a  later  time. 
We  estimate  that  the  surveillance  sensor(s)  should  provide  the  following  capability 
(all  values  shown  except  response  time  are  one-sigma) 

Position  Accuracy  20-30  ft 

Velocity  Accuracy  2-3  fps 

Directional  Accuracy  10  degrees  (for  Turn  Recognition) 

Response  Time  2-3  seconds 

with  a  sample  period  of  the  same  magnitude  as  the  Response  Time. 

If  velocity  data  is  to  be  derived  from  position  measurements,  it  is 
estimated  that  a  more  stringent  position  accuracy  will  be  required.     This  is  esti- 
mated to  be  about  10  feet.    However,  an  alternative  of  higher  sample  rates  (e.g.  , 
10  samples/second)  will  relax  this  requirement  back  to  20-30  ft. 


The  estimates  made  by  our  subcontractor,  Bendix,  for  the  GCS  are 

Position  ±50  feet 

Velocity  ±5  percent  (about  2.  5  fps  for 

V  =  30  knots) 

Directional       ±20  degrees 

No  response  time  values  have  been  provided  by  Bendix. 

Resolution  requirements  for  the  GCS  are  based  upon  physical  charac- 
teristics of  the  airport  with  the  ability  to  resolve  an  aircraft  on  the  Inner  Circular 
from  one  on  the  Outer  as  a  limiting  case.  Resolution  capabilities  of  about  200  ft, 
from  aircraft  center  to  aircraft  center,  appear  necessary. 

The  estimated  sensor  performance  requirements  for  the  semi-auto- 
mated LCS  must  be  given  for  airborne  aircraft  and  for  surface  aircraft.  The  LCS 
must  provide  airborne  coverage  out  to  5  nmi  from  runway  thresholds  and  ground 
coverage  of  all  runways  as  well  as  the  entrance  and  exit  links  interfacing  with  the 
runways.    Resolution  capabilities  of  the  airborne  area  of  the  LCS  are  estimated 
as  1000  ft  in  order  to  separate  aircraft  on  parallel  approaches  and  to  distinguish 
aircraft  on  different  altitudes.    In  the  ground  position  of  the  LCS,  resolution  capa- 
bilities of  about  200  ft  should  permit  recognition  of  aircraft  exiting  the  Local  Con- 
trol Departure  Q  area  as  well  as  resolution  of  aircraft  on  the  runways  from  those 
on  the  parallels. 

The  estimated  performance  requirements  of  the  ground  position  of  the 
LCS  (one-sigma  values  except  for  Response  Time)  are  as  follows: 

Position  Accuracy  20  ft 

Velocity  Accuracy  2-3  fps 

Directional  Accuracy  5-10  degrees 

Acceleration  Accuracy  1.  6  fps 

Response  Time  1-2  seconds 


with  a  sample  period  of  the  same  magnitude  as  the  Response  Time.  As  with  the 
GCS,  if  position  is  used  to  estimate  velocity  either  a  greater  positional  accuracy 
(10  ft)  or  a  higher  position  sample  rate  (10  samples/second)  is  required. 

For  surveillance  of  airborne  aircraft,  the  estimated  accuracy  require- 
ments of  the  LCS  are 

Position  Accuracy  150  ft 

Velocity  Accuracy  8  fps 

Directional  Accuracy  15  degrees  (Departure  Routing) 

Response  Time  1-2  seconds 

with  a  sample  period  of  the  same  magnitude  as  the  Respone  Time. 

The  estimates  provided  by  Bendix  for  the  LCS  are  as  follows: 


Ground 

Airborne 

Aircraft 

Aircraft 

Position  Accuracy 

±30  ft 

±100  ft 

Velocity  Accuracy 

±2  percent 

3  fps 

Directional  Accuracy 

±10  degrees 

±20  degrees 

No  response  times  have  been  provided  by  Bendix  at  this  time. 

The  independent  estimates  of  CSC  and  Bendix  given  above  do  not  differ 
significantly.    Both  companies  recognize  the  significance  of  velocity  for  such  pur- 
poses as  Movement  Recognition  as  well  as  prediction.    The  need  for  some  type  of 
"heading"  (aircraft  fuselage  direction)  or  "course"  (velocity  vector  orientation) 
is  recognized  for  such  diverse  purposes  as  Turn  Recognition,  Turnoff  Recognition, 
Departure  Routing,  Turn  onto  Runway,  etc.    The  achievement  of  this  capability 
from  a  series  of  position  measurements  must  be  further  investigated  if  the 
necessary  algorithms  are  to  be  developed  and  evaluated. 

Combining  the  requirement  of  the  GCS  and  the  ground  portion  of  the 
LCS  (since  these  can  possibly  be  provided  by  one  sensor  subsystem)  results  in 
the  following  composite  requirements  for  surface  aircraft: 


Position  Accuracy 
Velocity  Accuracy 
Directional  Accuracy 
Acceleration  Accuracy 
Response  Time 


20  feet 
2-3  fps 
5-10  degrees 
1.6  fps 
1-2  seconds 


with  a  sample  period  of  the  same  magnitude  as  the  Response  Time. 

If  position  is  to  be  used  for  derivation  of  velocity  and/or  directional 
data  either  a  position  accuracy  of  the  order  of  10  feet  or  a  sample  rate  on  the 
order  of  10  samples/second  will  be  required. 


APPENDIX  A  -  CHARACTERISTICS  OF  THE  TAXIWAY  NETWORK 


The  taxiway  network  at  O'Hare  will  be  described  in  terms  of  links  and  nodes  (or 
intersections);  it  serves  traffic  primarily  between  the  ramp  exit/entrance  nodes 
and  the  runway  nodes  (Departure  Q  areas  and  runway  turnoffs).     The  control  of 
port  surface  traffic  (i.e. ,  the  management  of  these  taxi  facilities)  will  be  strongly 
influenced  by  such  physical  characteristics  of  the  network  as  link  size  (length)  and 
network  connectivity.    Other  factors  such  as  the  active  runway  configuration,  air- 
craft equipment  characteristics,  and  traffic  loads  must  also  be  considered  in  the 
control  process. 

The  nodes  at  O'Hare,  considering  primarily  the  South  side  of  the  airport,  may  be 
considered  to  fall  into  one  of  the  following  classes: 

Ramp  Nodes  (R) 
Inner  Circular  Nodes  (I) 
Outer  Circular  Nodes  (O) 
South  Taxiway  Nodes  (S) 
Runway  Turnoff  Nodes  (Y) 

The  connectivity  between  these  classes  of  nodes  may  be  described  in  matrix  format 
as  shown  in  Figure  A-l;  note  that  connectivity  may  exist  only  between  certain  classes 
(i.e.,  no  single  link  exists  between  any  Inner  Circular  and  South  Taxiway  nodes). 
The   diagonal  entries  in  this  matrix  (I/I  for  example)  represent  "highways"  while 
the  off-diagonal  entries  represent  interconnecting  links  between  the  "highways", 
or  between  the  entry/exit  modes  and  highways. 

A  representation  of  the  flow  of  aircraft  through  these  links  and  nodes  is  shown  in 
Figure  A-2  for  both  Departures  and  Arrivals.     Figure  A-3  shows  the  taxiing  process 
for  Departures  in  finer  detail.    The  number  of  links  traversed  on  the  major  arteries 
varies  from  aircraft  to  aircraft;  however,  only  a  single  interconnecting  link  (I/O, 
O/S)  of  each  category  will  normally  be  used  in  the  taxiing  process  at  O'Hare. 
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Figure  A-l.     Connectivity  Matrix  for  Node  Classes 
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Aircraft  movement  involving  cargo,  hangar,  or  penalty  box  areas  have  not  been 
considered  at  this  time. 

The  detail  portions  of  the  connectivity  matrix  are  examined  below;  Figure  A-4 
illustrates  the  numbering  scheme  employed.    The  nine  ramp  areas  (B-C  has  been 
included,  although  seldom  used)  have  been  considered  as  having  12  nodes,  since 
several  ramp  areas  appear  capable  of  handling  two  operations  simultaneously  (A-B, 
E-F,  and  H-K).     The  adjacent  Inner  Circular  nodes  will  define  the  permissible 
Ramp/Inner  (R/l)  links;  these  are  indicated  in  the  upper  left  section  of 
Figure  A -5  which  provides  the  details  on  the  R/I  portion  of  the  connectivity  matrix 
previously  described.    While  only  one  entry  is  shown  for  each  link,  this  submatrix 
may  of  course  be  expanded  to  include  traffic  direction  by  defining  columns  as 
"sources"  and  rows  as  "sinks"  as  has  been  done  for  the  INNER,  OUTER,  and 
South  highway  links  (I/I;  O/O;  S/S). 

The  center  of  the  intersection  has  been  used  at  this  time  for  evaluation  of  link 
distance.    The  R/I  links  are  quite  short,  averaging  about  175  feet.    The  I/I  and 
O/O  links  are  also  relatively  short;  we  estimate  that  7  of  the  15  I/I  links  are  less 
than  350  feet  long  and,  therefore,  cannot  serve  as  aircraft  holding  locations  with- 
out interfering  with  adjacent  nodes  and/or  links.    The  O/O  links  average  over  600 
feet  in  length  and  are  relatively  equal  in  size;  each  appears  capable  of  a  "Hold" 
without  hampering  adjacent  node  and  crossing  link  usage. 

The  interconnecting  links  between  the  Inner  and  Outer  (I/O)  are  also  short  (around 
275  feet  in  length)  and  should  not  usually  be  used  for  holding.    It  is  not  until  aircraft 
reach  the  S/O  links  that  sufficient  length  exists  for  implementing  non-interfering 
"holds".     These  seven  links  range  from  400  feet  to  700  feet  in  length,  excluding 
the  bypass  and  0-10/0-13  link. 

A  summary  of  the  links,  nodes,  and  the  associated  center/center  link  distances 
is  given  in  Table  A-l.    The  common  taxi  area  serving  both  the  North  and  South 
sides  of  the  airport  includes  about  3, 150  linear  feet  of  R/I  links,  an  INNER  high- 
way of  7,  000  feet,  an  OUTER  highway  of  8,  000  feet,  and  the  short  I/O  links  com- 
prising about  4,  000  linear  feet. 
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Figure  A-5b.    Detail  Connectivity  Matrix  O'Hare  Airport 


On  the  other  hand,  the  South  taxLways  north  of  the  runways  offer  about  14,  000 
feet  of  pavement;  note,  however  that  the  seven  S/O  links  (of  which  only  part  are 
used  depending  on  the  runways  in  use)  offer  about  3,  500  feet  of  taxi  surface. 

Runway  nodes  include  both  "turnoffs"  as  well  as  Departure  Q  locations  (which  may 
also  be  used  for  turnoffs  when  the  runway  direction  is  reversed).    R/W  crossing 
nodes  have  been  separately  identified  in  Figure  A-6  which  portrays  the  common  and 
South  side  taxi  structure  on  a  "flow",  or  logical  basis.     This  type  of  display  pres- 
entation may  be  desirable  for  some  of  the  control  functions. 

Excluding  ramp  entry/ exit  nodes  the  South  side  of  O'Hare  has  64  nodes  or  inter- 
sections including  9  which  are  runway  turnoffs  only.    Of  the  total  of  98  links  on  the 
South  side  (excluding  turnoffs),  40  are  less  than  350  feet  in  length. 


Table  A 


-1.    Summary  of  Common  and  South  Taxiway  Facilities  -  O' 


'Hare 


Ramp  Area  (R) 

Number  of  Ramp  Areas  with  Single  Node 
Number  of  Ramp  Areas  with  Dual  Nodes 

6 
3 

Inner  Circular  Highway  (I/I) 

16 
15 

7000  ft 

7  (Links  1-2,  4-5,  5-6,  i 
11-12,   13-14,   14-15) 

-10, 

Number  of  Nodes 
Number  of  Links 
Total  Length  of  Inner  Circular 
Number/Identification  of  Links  less 
than  350  ft  long 

Ramp/Inner  Circular  Links  (R/I) 

Number  of  Links 
Link  Distance 

Maximum 

Average 

Minimum 

18 

225  ft 
175  ft 
140  ft 

Outer  Circular  Highway  (O/O) 

Number  of  Nodes 
Number  of  Links 
Total  Length  of  Outer  Circular 

13 
12 
8000  ft 

Inner/Outer  Links  (I/O) 

Number  of  Links 
Link  Distance 

15 

275  ft  (little  variation  between 
links) 

South  Taxiway  (S)  -  Parallels  -  Highway 

13 
12 

8850  ft  (S-l/S-8) 
3800  ft  (S-8/S-11) 
550  ft  (S-ll/S-12) 
850  ft  (S-12/S-13) 

Number  of  Nodes 
Number  of  Links 
Total  Length  (S-l  to  S-13) 

South/Outer  Links  (S/O) 

Number  of  Links 

Link  Distance  (excluding  Bypass  and 
O-lO/S-13  Link  of  200  feet) 

7 
400-700  ft 

APPENDIX  B  -  AIRCRAFT  MOVEMENT  PROFILE  CHARACTERISTICS 

INTRODUCTION 

Aircraft  maneuvers  on  the  airport  surface  will  be  of  importance  in  the  require- 
ments establishment  process.    These  maneuvers  will  be  a  function  of  the  aircraft 
equipment  type  as  well  as  the  constraints  imposed  by  the  taxiway  network.    In 
general,  aircraft  speed  will  vary  directly  with  distance  from  the  terminal  since 
links  are  longer  farther  out  from  the  terminal.    In  the  following  sections,  estimates 
of  velocities  for  various  aircraft  maneuvers  will  be  used  with  the  geometrical 
values  of  the  taxiway  network  (Appendix  A)  to  obtain  estimated  time  parameters 
for  the  various  maneuvers. 

Links  have  been  considered  as  extending  from  node-center  to  node-center  since  in 
many  cases  an  aircraft  moving  on  a  short  link  must  be  considered  as  occupying  the 
upcoming  intersection,  i.e.  ,  there  is  insufficient  room  to  stop  without  blocking  the 
intersection.  The  rationale  for  link  and  node  control  is  not  discussed  in  this  sec- 
tion. 

Aircraft  acceleration  and  deceleration  have  been  considered  as  constant  values 
between  the  initial  and  final  velocities.     Figure  B-l  present  the  velocity  and  dis- 
tance variations  vs  time  for  accelerations  of  0.  1  to  0.  3  g's  which  are  those  ex- 
pected on  the  taxiway  surface.    It  is  assumed  that,  after  an  aircraft  reaches  the 
desired  speed,  its  acceleration  will  drop  to  zero.     These  relationships  have  been 
used  in  developing  the  estimates  described  below.    Aircraft  length  has  been  taken 
as  250  ft    (a  747  is  about  232  ft. )  and  as  80  ft    for  small  aircraft. 

RAMP/INNER  (R/l)  LINKS 

Three  types  of  situations  will  be  examined.    Departure  aircraft  may  transit  R/l 
links  either  after  having  come  to  a  full  stop  at  the  ramp  exit  or  may  move  directly 
out  (i.e.  ,  cleared  to  taxi  instruction  already  received)  without  stopping.    Arrival 
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Figure  B-l.    Distance  and  Velocity  Change  for  Constant 
Acceleration  Levels 
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aircraft  will  not  be  held  on  R/l  links  and  will  move  directly  into  the  ramp  area. 
While  Appendix  A  describes  R/l  distances  on  a  straight  line  basis,  in  many  cases 
some  aircraft  turning  is  involved  in  the  ramp  exit/entry  maneuver. 

Measurements  of  Arrival  aircraft  movement  in  the  ramp  area  indicate  an  average 
time  from  entrance  to  docking  of  76  seconds.    Allowing  40  seconds  to  45  seconds 
for  the  turn-in  and  docking  phase  of  this  operation,  it  is  estimated  that  the  average 
aircraft  travels  straight  in  for  about  400  ft.   in  a  period  of  31  seconds  to  36  seconds, 
i.  e.  ,  an  average  speed  of  11  fps  to  13  fps  (around  7  knots  to  8  knots). 

To  estimate    the  R/l  parameters  we  shall  use  final  velocities  of  5  knots  to  10  knots 

2 
(8.  5  fps  to  17  fps)  and  accelerations  of  0.  1  to  0.  15  g's  (3.  2  to  4.  8  fps  ).     Using 

the  minimum  and  maximum  R/l  distances  of  150  ft.   and  250  ft.   we  may  estimate 

the  occupancy  time  of  the  R/l  links  under  various  departure  aircraft  situations,  or 


R/I  = 

150  feet 

R/I  = 

250  feet 

V  =  5  knots 

10  knots 

5  knots 

10  knots 

After  Stopping 
for  a  =  0.  1  g 

19 

11.6 

31 

17.4 

for  a  =  0. 15  g 

18.5 

10.2 

30.2 

16.5 

Without  Stopping 

17.5 

9 

29.5 

15 

These  occupancy  times  are  measured  with  respect  to  a  common  point  on  the  air- 
craft, i.e.  ,  the  nose,  for  example. 

Link  occupancy  time  is  relatively  insensitive  to  start-up  acceleration  and  the 
entry  mode  (with  or  without  a  stop).     Distance  and  taxiing  velocity  appear  to  be 
the  most  significant  parameters.    On  longer  R/l  links  it  is  believed  that  higher 
aircraft  velocities  (10  knots  rather  than  5  knots)  would  be  used.     We  shall  consider 
the  normal  range  of  R/l  occupancy  times  for  Departures  to  be  10  seconds  to  20  sec- 
onds for  distances  of  150  feet  to  250  feet  and  speeds  of  5  knots  to  10  knots. 

Similar  values  will  be  used  for  Arrivals  recognizing  that  the  lower  time  intervals 
are  more  likely. 


COMMON  LINKS  -  (i/l,  O/O,  O/l) 

These  links  involve  both  the  Inner  and  Outer  highways  as  well  as  the  O/l  links 
between  them.    It  is  estimated  that  taxi  speeds  of  from  10  knots  to  15  knots  are 
most  likely  in  these  areas  with  link  occupancy  times  of  from  15  seconds  to  25  sec- 
onds for  distances  of  300  feet  to  700  feet  when  approximately  uniform  speed  is 
maintained. 

TRANSITION  AND  SOUTH  LINKS  (O/S  and  S/S) 

These  links  include  both  the  South  parallels  as  well  as  the  O/S  interconnections 
and  (because  of  the  longer  lengths  involved)  it  is  expected  that  average  taxi  veloc- 
ity will  range  from  15  knots  to  25  knots.     For  the  distances  set  forth  in  Appendix  A, 
it  is  estimated  that  occupancy  time  of  between  15  seconds  to  30  seconds  will  be 
normal.    Only  slight  changes  in  acceleration  are  expected  on  these  links. 

TURN  DURATION 

For  90  degree  turns  it  is  estimated  that  between  10  seconds  and  15  seconds  will  be 
required  from  the  entrance  of  the  undercarriage  into  the  intersection  until  it  enters 
the  next  link.    These  values  may  be  used  as  additional  time  factors  to  be  added  to 
the  normal  link  traversing  (occupancy)  times. 

TURNOFF  LINKS 

Runway  turnoffs  vary  from  90  degree  turns  to  high  speed  exits;  in  general,  the 
latter  are  larger.    An  exiting  aircraft  must  be  prepared  to  stop  before  entering 
the  taxiway  system  at  the  adjacent  parallel.    Using  deceleration  values  of  from 
0. 1  to  0.  3  g's,  and  turnoff  velocities  of  from  20  knots  to  35  knots,  it  is  estimated 
that  turnoffs  will  be  occupied  between  5  seconds  to  8  seconds  when  no  stopping  is 
involved. 

NODE  CROSSINGS 

Two  situations  are  of  interest  here.    In  one,  the  node  or  intersection  is  traversed 
by  the  aircraft  without  stopping.    In  the  other  the  aircraft  has  been  stopped  and 


must  accelerate  to  cross.    We  have  used  400  ft.  as  the  maximum  distance  to  be 
traveled  by  the  crossing  aircraft.     This  is  based  upon  75  foot  taxiways,  75  foot 
clearance  before  crossing,  and  the  selected  length  of  the  747  (250  ft. )  For  smaller 
aircraft  (80  ft.  in  length)  the  distance  has  been  taken  as  230  ft.     The  crossing 
values  of  10  seconds  to  24  seconds  (without  a  stop)  and  15  seconds  to  26  seconds 
after  stopping  represent  estimates  and  not  exact  computations. 

RUNWAY  CROSSING 

Estimates  for  time  required  to  cross  runways  have  been  made  in  the  same  manner 
as  for  node  crossings,  except  higher  accelerations  and  final  speeds  have  been 
assumed.    A  runway  width  of  200  ft.  has  been  used  and  only  the  stop  and  go  values 
are  shown    since  this  is  the  more  common  situation.     Two  to  three  seconds  could 
be  eliminated  from  the  15  second  to  25  second  estimates  of  runway  crossing  time 
if  a  non-stopping  situation  was  involved.    It  may  be  noted  that  duration  of  aircraft 
"Holds"  as  measured  at  O'Hare  averaged  from  40  seconds  to  90  seconds  for  the 
various  runs. 

AIRCRAFT  STOPPING  PARAMETERS 

Two  estimates  have  been  made  of  the  time  required  for  an  aircraft  to  stop  at  de- 
celerations of  0.2  to  0.3  g's.     Initial  velocities  of  30  knots  and  20  knots  have  been 
assumed  in  these  two  estimates.    Stopping  time  ranges  from  4.  5  seconds  to  6  sec- 
onds in  the  latter  case  and  from  6  seconds  to  9  seconds  in  the  former;  the  asso- 
ciated distances  range  from  90  ft.   to  2  50  ft.   including  pilot  reaction  time  of  0.  5  sec- 
ond to  1.  0  second.     These  values  are  of  use  in  establishing  minimum  desired  air- 
craft separation  ("headway")  on  highways  or  longer  links. 

SUMMARY 

A  summary  of  the  above  parameters  is  presented  in  Table  B-l.    As  a  check  in 
their  applicability,  a  hypothetical  departure  route  involving  the  following  segments 
may  be  compared  to  actual  measured  taxi  times  (without  stops). 


Table  B-l.    Estimates  of  Aircraft  Maneuver  Parameters 


Est  Velocity 
Range 

Distance 
ft  (4) 

Acceleration 
Range 
fps(2) 

Occupancy 

Time  (Est) 

Sec 

Ramp/Inner  Links 

5-10  knots 
(8.5-16.9  fps) 

150-250 

0-4.8 
(0-0. 15  g) 

10-20 

Common  Links  (W/O  Stop) 
I/I;  O/O;  O/I 

10-15  knots 
(16.9-25.5  fps) 

300-700 

0 

15-25 

Transition  and  South  Links 
O/S  and  S/S 

15-25  knots 
(25.  5-42  fps) 

400-1000 

0-3.2 
(0-0.  1  g) 

15-30 

Turn  Time  (90°) 

10-15 

Turnoff  Link  (Arrivals) 

20-35  knots 
(34-60  fps) 

250-500 

3.2-9.6 
(0.  1-0.3  g) 

5-8 

Node  (90°)  Crossing 
From  Stop 
W/O  Stop 

0-15  knots 
10-20  knots 

230-400(1) 

0-4.8 
0 

15-27 
10-24 

R/W  Crossing  (After  Stop) 

0-25  knots 

380-550  (2) 

0-6.4 

15-25 

Aircraft  Stopping  Parameters 

30  ■*  0  knots 
20  -  0  knots 

180-250  ^ 
90-120  { ' 

6.4-9.6 
6.4-9.6 

6-9 
4.5-6 

NOTES 

1.  Based  on  75'  T/W,  75'  Clearance,  70'  or  250'  Aircraft  Length. 

2.  Based  on  75'  +  200'  +  250*  (or  70')  +  25'  Clearance. 

3.  Includes  pilot  reaction  times  of  0. 5-1.  0  seconds. 

4.  Link  distances  defined  from  node  center  to  node  center. 


R/I  Link  (1) 

Turn 
I/I  Links  (2) 

Turn 
I/O  Link 

Turn 
O/O  Links  (3) 

Turn 
O/S  Link 
R/W  Crossing 
S/Y  Link 


226  seconds 


Average  departure  taxi  times  measured  on  the  South  side  of  O'Hare  ranged  from 
209  seconds  to  235  seconds  for  Runway  9R;  this  configuration  is  similar  to  the 
hypothetical  model  evaluated  above. 


APPENDIX  C  -  LINK/NODE  OCCUPANCY  CONSIDERATIONS 

The  logic  for  use  of  position  information  must  consider  the  constraints 
imposed  by  the  characteristics  of  the  facilities  (links  and  nodes),  aircraft  dimen- 
sions, and  clearance  requirements.     Figure  C-l  shows  the  geometry  of  a  sample 
link  between  nodes  A  and  B.    We  shall  assume  that  a  position  sensor  can  provide 
an  estimate  of  X,  the  distance  from  the  centerline  of  the  intersection  to  the  center 
of  the  aircraft.    The  lengths  of  various  types  of  aircraft  are  shown  in  Figure  C-2. 

If  the  error  in  the  position  sensor  is  considered  a  normal  distribution 
with  mean  of  zero  and  standard  deviation  a  and  the  test  for  link  occupancy  (i.  e.  , 
Node  A  clearance)  is  sensed  position  (X  )>X  ,  then  the  minimum  value  of  X  that 
will  indicate  the  aircraft  is  clear  of  the  intersection  with  97.  5  percent  certainty 
is  X  +  2a  ;  and  the  value  of  X  which  will  guarantee  with  97.  5  percent  certainty 
that  an  aircraft  within  the  intersection  will  indicate  intersection  occupancy  (i.e. , 
Node  A  occupancy) is 

v     =  r  4.  -  - 

2       2 

Similarly,  if  the  test  for  link  occupancy  on  the  other  end  (i.  e.  ,  Node  B  clearance) 
is  X  <  X  ,  then  the  maximum  value  of  X  that  will  indicate  the  aircraft  is  clear  of 
the  intersection  with  97.  5  percent  certainty  is  X  -  2a  •  and  the  value  of  X  which 
will  guarantee  with  97.5  percent  certainty  that  an  aircraft  within  the  intersection 
will  indicate  intersection  occupancy  (i.e.  ,  Node  B  occupancy)  is 


The  difference  between  the  two  values  of  X  within  which  detection  on 
the  link  (i.  e. ,  not  in  either  intersection)  is  assured  (with  greater  than  97.  5  percent 
certainty)  is  given. 

AX  =  (X    -  2a  )  -  (X    +  2a   )  =  D  -  2C  -  L  -  W  -  8a  . 


itr 

o 

v          — 

!     ll      ^      ' 

3 

75'T-- 

HI  K 

L    r- 

*"lw  = 

xi=t  +  c  +  2^+t 


W  =  TAXIWAY  WIDTH  (75'  NOMINAL) 
L  =  A/C  LENGTH 
D=LINK  LENGTH 
C  =  REQUIRED  CLEARANCE  (75') 
a    =  POSITION  SENSOR  ERROR  STANDARD  DEVIATION 
X.  =  TEST  VALUE  OF  X  TO  INDICATE  A/C  IS  CLEAR  OF 

INTERSECTION  A 
X-  =  TEST  VALUE  OF  X  TO  INDICATE  A/C  HAS  NOT 
ENTERED  INTERSECTION  B 


Figure  C-l.    Representative  Link/Node  Geometry 
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Figure  C-2.    Aircraft  Size  Categories 


If  the  parameters  are  such  that  AX  <  0,  then  detection  of  the  aircraft  on  the  link 
clear  of  both  intersections  cannot  be  assured. 

Consider  a  B747  aircraft  and  the  parameters  L  =  235  ft,  C=  75  ft, 
W  =  75  ft.  With  perfect  sensing  (a    =  0)  the  link  must  be  longer  than  460  ft  to  hold 
a  B747  clear  of  both  intersections.  Evenfor  a  more  common  aircraft  length 
(L  =  150  ft)  the  required  length  is  375  ft.    As  shown  in  Appendix  A,  many  links  will 
not  meet  this  criteria. 

As  can  be  seen  from  the  AX  equation,  position  error  will  require  a 
longer  link  to  assure  detection  of  an  aircraft  clear  of  both  intersections  than  is 
actually  required.  For  an  aircraft  of  150  ft  length  the  link  length  required  for 
position  errors  (a  )  of  10,  20,  and  30  ft  are  455,  535,  and  615  ft,  respectively. 
This  is  in  contrast  to  the  375  ft  actually  required.  The  span  of  these  lengths  ex- 
ceeds commonly  used  holding  links  (e.g. ,  the  Stub  and  Outer/South,  North/South 
taxi  ways;  see  Appendix  A)  and  may  cause  serious  system  problems. 


APPENDIX  D  -  MOVEMENT  DETECTION 

As  part  of  the  control  process  it  will  be  necessary  to  have  the  capa- 
bility for  recognition  of  a  change  in  aircraft  status  between  a  moving  and  non- 
moving  condition  as  well  as  to  distinguish  a  moving  and  stopped  aircraft.    In  the 
simplest  case  no  acceleration  is  present  and  a  velocity  measurement  must  have 
sufficient  accuracy  to  separate  the  two  conditions.    If  the  error  in  the  velocity 
measurement  is  considered  a  normal  distribution  with  mean  of  zero  and  standard 

deviation  a    and  the  test  for  movement  is  V      >  V    .     (V     being  the  velocity  mea- 
v  m-     mm      m 

surement),  then  the  minimum  value  of  V  that  will  indicate  the  aircraft  is  moving 

with  97.5  percent  certainty  is  V    .     +  2a  ;  and  the  value  of  V    .     which  will  guar- 
min  v  min 

antee  with  97.  5  percent  certainty  that  a  standing  aircraft  will  not  indicate  it  is 
moving  is  V    .    =  2a  .    Before  applying  these  relationships  in  determining  the  a 
requirement,  the  impact  of  sampling  is  examined. 

In  the  worst  case,  an  aircraft  can  accelerate  from  a  stopped  condition 

and  attain  the  velocity  assuring  detection  (V  =  V    .     +  2a  )  just  after  a  sample  was 

taken.    In  this  instance  the  delay  in  movement  detection  will  be 

V     .     +  2a 
mm  v  + 

DW  a  S 

where  a  is  the  acceleration,  T    is  the  sample  period  and  T        is  the  worst  case 
S  DW 

delay. 


in  movement  detection  (T      )  will  be 


To  illustrate  possible  ranges  of  the  various  parameters,  Table  D-l 
has  been  prepared  for  a  =  0.  lg,  and  V  =  7.5  knots  or  12.  5  knots  respectively; 


Table  D-l.    Estimates  of  Velocity  Accuracy  and  Sampling  Rates  for 
Movement  Detection  Based  on  Velocity  Measurement 


V 

T 

T 

T 

V 

V 

min 

S 

DA 

DW 

(fps) 

(fps) 

(fps) 

(sec) 

(sec) 

(sec) 

12.7 

3.2 

6.4 

2 

3.0 

6.0 

(7. 5  knots) 

4 

4.0 

8.0 

6 

5.0 

10.0 

21.2 

5.3 

10.6 

2 

4.3 

8.6 

(12.  5  knots) 

4 

5.3 

10.6 

6 

6.3 

12.6 

the  former  value  represents  an  average  velocity  estimated  in  the  Ramp/Inner  area 

while  the  latter  represents  a  velocity  estimate  expected  to  be  exceeded  by  most 

aircraft  outside  of  this  area.    V    .    was  chosen  such  that  the  velocity  values 
mm 

equalled  the  minimum  value  of  V  which  would  indicate  the  aircraft  was  moving 

with  97.  5  percent  certainty,  V    .    +  2a  .    Since  V    .    =  2a    would  give  less  than 
J'     min         v  mm         v 

2. 5  percent  probability  of  false  alarm  (i.  e. ,  indication  a  standing  vehicle  is 


velocity  estimate 


=  2a 


velocity  estimate 

2 


This  table  indicates  that  a  sampling  interval  of  four  seconds  would 
satisfy  the  four  to  seven  second  detection  requirement  on  the  average;  however, 
the  required  velocity  accuracy  would  be  set  by  the  Ramp/Inner  taxi  speeds  at 
3.  2  fps.    If  detection  in  the  Ramp /Inner  area  was  compromised  with  respect  to 
probability  of  detection  a  less  strict  velocity  accuracy  of  5. 3  fps  could  be  adopted 
with  a  sampling  period  of  two  seconds.    However,  this  should  be  avoided. 

The  measured  velocity  can  be  obtained  from  some  sensors  directly. 
More  relevant  to  this  study  is  a  velocity  estimate  based  upon  position  information. 


If  a  single  position  measurement  is  taken  at  the  end  of  each  velocity 
sample  period,  X    ,  and  the  beginning  of  each  sample  period  (i.  e. ,  the  end  of  the 
last  sample  period),  X    ,  a  simple  velocity  estimate  would  be 

X^  -  X„ 


If  the  positional  error  is  assumed  to  be  uncorrelated  and  normal  with 

zero  mean  and  a    standard  deviation,  the  velocity  measurement  deviation  is 
x 

1/2 

0    =  ~    o 
v      Tg     x 

Using  T    =  4  seconds  and  a    =  3.2  fps  or  T    =  2  seconds  and  a  =  5.3 

S  v  S  v 

fps  the  positional  accuracy  would  be,  respectively 

a    T 
a  =-^—^  =  9.1  ft  and  7.6  ft 

x     VF 

It  can  be  seen  that  no  apparent  advantage  exists  in  opening  up  the 
velocity  error  since  the  effect  of  reducing  the  sample  period  more  than  offsets  it. 

The  position  estimates  X     and  X     can  represent  smoothed  values  of 
B  h 

M  measurements  based  upon  an  observation  interval  equal  to  (M-l)  t    where  t    is 
the  interval  between  samples. 

If  a  is  the  smoothed  value  of  these  measurements  and  a    is  the  standard 

x 

deviation  of  individual  measurements  the  curves  of  Reference  1  may  be  used  to 

determine  a/a    vs  M  for  a  first  order  filter,  or 
x 

M  =    26  11  6      points 

a/ a        0.38      0.57       0.75 
x 

excluding  truncation  effects.    For  example,  if  (M-l)  t    is  fixed  at  2.5  seconds,  t 
would  range  from  0. 1  (10  samples/sec)  to  0.5  seconds  for  the  values  of  M  shown. 


The  required  single  measurement  position  accuracy  required  for  movement  recog- 
nition for  M  =  26  would  then  be 

a    =^_  =  ^l  =  24ft 
x      0.38      .38 

Note  that  this  relaxation  of  position  accuracy  is  bought  at  the  price  of  increased 
data  (sampling)  rate  by  a  factor  of  40.    In  addition,  the  time  delay  is  increased  by 
the  position  sample  interval  (M-l)  t    resulting  in  an  average  delay  of  6. 5  seconds 
and  worst  case  delay  of  10. 5  seconds.    The  four  to  seven  second  criteria  is  just 
satisfied  on  the  average. 

So  far  velocity  measurement  and  position  change  have  been  examined 
as  movement  detection  devices.  A  "passage"  detector  can  provide  movement  recog- 
nition at  a  particular  point  since  it  essentially  recognizes  entry  into  a  particular 
area.    Such  devices  may  have  application  in  ramp  entrance/exit  areas,  possibly  at 
R/W  turnoffs,  and  on  the  link  preceding  the  Local  Control  Departure  Q.    The  ad- 
vantage is  the  lack  of  vehicle  identification. 
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APPENDIX  E  -  PREDICTION  ERRORS 

To  develop  a  rationale  for  an  airport  surface  traffic  control  system  consideration 
must  be  given  to  the  various  types  of  conflicts  that  can  occur.    We  shall  consider 
"conflicts"  as  those  combinations  of  events  which  can  lead  to  overlapping  demands 
from  two  or  more  aircraft  for  the  same  facilities  (i.  e.  ,  links  or  nodes).    An  exist- 
ing conflict  is  relatively  easy  to  recognize  since  the  location  of  one  aircraft  on  a 
link  or  at  an  intersection  is  either  preventing  the  second  aircraft  from  moving  or 
causing  it  to  slow  down.    An  example  of  the  former  case  might  be  denial  of  entry 
to  the  taxiway  system  for  an  aircraft  leaving  the  ramp  area  because  of  traffic  on 
the  Inner  or  Outer  directly  in  front  of  the  Ramp  Exit.    The  second  case  might  be 
that  at  an  intersection  wherein  one  aircraft  has  previously  been  instructed  to  give 
way  to  another  aircraft. 

Recognition  of  future  conflicts  (i.  e.  ,  conflict  prediction)  is  a  much  more  difficult 
process  requiring  in  many  cases  a  priori  knowledge  of  the  route   to  be  followed  by 
each  of  the  aircraft  involved,  as  well  as  other  aircraft  movement  parameters. 
At  any  instant  of  time  these  data  elements  permit  an  estimation  by  the  controller  of 
the  entry  and  exit  times  into  each  of  perhaps  the  next  several  links  and  nodes. 
Longer  prediction  intervals,  of  course,  will  have  higher  uncertainties;  most  con- 
trol decisions  in  the  Ground  Control  System  are  expected  to  be  based  upon  predic- 
tion intervals  of  from  15  seconds  to  30  seconds.    In  the  Local  Control  System  pre- 
diction intervals  as  long  as  2  minutes  to  3  minutes  may  be  feasible  because  of  the 
relatively  constant  aircraft  speeds  during  approach. 

The  controller  decisions  are  based  upon  an  estimate  of  future  aircraft  position  at  a 
particular  time  or,  from  another  viewpoint,  an  estimate  of  the  time  an  aircraft  will 
arrive  at  a  particular  location.    The  controller  is  essentially  therefore  predicting 
the  start  and  completion  times  that  an  aircraft  will  be  using  a  certain  facility,  i.  e.  , 
a  section  of  pavement.    This  prediction  process  is  currently  based  primarily  upon 
a  controller's  experience  (knowledge  of  pilot/aircraft  operations),  plus  the  inputs 
he  obtains  from  his  visual  surveillance  activities. 


To  illustrate  the  relative  contributions  of  position  and  velocity  errors  to  the  pre- 
diction process,  the  relationship  given  in  Reference  1  may  be  used  to  estimate  the 
error  in  arrival  time  caused  by  uncertainties  in  velocity  and/or  initial  position  of 
an  object  moving  on  a  straight  line  path.    This  relationship 

(1) 


(2) 


t       v2     x      \^J       V        tl         t2 

assumes  independent  Gaussian  errors  for  x  and  V.    If  future  velocity  is  known 
exactly,  the  predicted  time  error  will  depend  solely  on  the  first  term,  i.e. , 

a     mla 

tl      V     x 


or  on  the  accuracy  of  the  present  position  estimate  and  the  speed  of  the  taxiing  air- 
crafts  during  the  prediction  interval.    On  the  other  hand,  if  a    is  zero,  the  accuracy 
of  the  predicted  occurrence  of  arrival  at  a  designated  point  will  be  a  function  of  time, 
as  well  as  velocity  magnitude  and  its  error,  i.  e.  , 

(3) 

The  predicted  time  error,  CT    ,  due  solely  to  position  inaccuracy  has  been  plotted  in 
Figure  E-l  as  a  function  of  average  velocity,  V,  during  the  prediction  interval.    For 
low  value  of  velocities  the  prediction  error  becomes,  as  expected,  quite  large  since 
of  course  it  is  impossible  to  predict  the  future  time/location  of  a  non-moving  object. 
The  range  of  estimated  aircraft  velocities  in  the  various  portions  of  the  taxiway  sys- 
tem described  in  Appendix  A  is  also  indicated  on  this  figure.    An  interpretation  of 
this  plot  might  be  as  follows.    If  a  ,  the  uncertainty  in  present  aircraft  position  is 
25  feet,  and  the  aircraft  is  expected  to  maintain  exactly  10  knots  in  the  future, 
there  will  be  an  la  uncertainty  of  about  ±1.4  seconds  in  the  prediction  of  the  air- 
craft's arrival  at  a  future  point  due  solely  tocr    .    Therefore,  if  a  particular  link 
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Figure  E-l.     Prediction  Time  Error  Due  to  Initial  Position  Errors 


was  to  be  scheduled  for  use  by  this  aircraft  and  the  aircraft  nominally  occupied  the 
link  for  15  seconds,  the  controller  would  have  to  reserve  the  link  for  a  larger  inter- 
val of  time.    Allowing  2a  at  the  beginning  and  end  of  the  nominal  15-second  occupancy 
interval,  the  link  would  have  to  be  reserved  for  15  +  2  (2.  8)  or  20.  6  seconds. 

The  prediction  errors,  a       due  to  velocity  variations  during  the  prediction  interval 
has  been  plotted  in  Figure  E-2  vs  prediction  interval,  "t  "  for  several  values  of 
a     I    .    These  latter  values  have  been  estimated  has  follows.    Assume  the  aircraft 
is  moving  in  a  known  area  of  the  airport  (on  the  South  links,  for  example)  and  its 

velocity  will  normally  lie  between  15  knots  and  25  knots.    For  a  rectangular  distri- 

25-25 
bution  we  may  use  a     =  =  2.  85  knots  or  a  j    =  0.  142.    Closer  to  the  ter- 

minal the  velocity  range  might  normally  be  expected  to  be  from  5  knots  to  15  knots 
or  ffv/v  =  0.  282.    If  closer  estimates  of  cr     are  possible — say  to  a  5  knot  range 
between  10  knots  and  15  knots — CTV/V  might  be  as  small  as  0. 12  for  this  range  of 
velocities. 

As  shown  above,  the  uncertainty  in  prediction  time  is  a  function  of  present  position 
accuracy  and  the  variation  in  aircraft  velocity  that  occurs  during  the  prediction 
interval.    To  minimize  the  contribution  of  position  error  to  the  prediction  uncertainty, 
the  basic  relationship  may  be  expressed  as 

1/2 


—  <  0.5 
at2" 


then 


i.  e.  ,  the  position  error  will  contribute  no  more  than  10  percent  to  the  prediction 
uncertainty. 


x  V  (4) 

Using  20  seconds  as  a  prediction  interval  and  a     =  4.  8  fps  (2.  85  knots)  the  required 
present  position  accuracy  to  meet  the  above  criteria  would  be 

a    =  0.5  (20)  (4.8)  =  48  feet 

If  the  position  accuracy  is  equal  or  better  than  this  value  the  prediction  uncertainty 
can  then  be  estimated  solely  from  the  a      vs  t  curves  of  Figure  E-2. 

Considering  the  various  prediction  intervals  ranging  from  15  seconds  to  45  seconds 
set  forth  in  the  section  on  System  Response  Time  it  is  estimated  that  position  ac- 
curacy equal  to 

a    =  0.5  (15)  (4.8)  =  36  feet 

would  be  acceptable  for  those  areas  of  the  airport  where  a  =4.8  fps  (2.  85  knots). 
For  areas  where  larger  velocities  will  occur  the  value  of  a  may  be  relaxed  from 
that  given  above. 

In  those  cases  where  position  accuracy  is  relatively  insignificant  the  accuracy  of 
the  prediction  process  may  also  be  estimated  from  Figure  E-2.     For  o    i     of  0.  15 
the  value  of  a     is  2.3  seconds  at  15  seconds.    At  the  end  of  an  additional  fifteen 
seconds  this  value  rises  to  4.6  seconds.    The  predicted  occupancy  time  of  a  link, 
for  example,  which  is  normally  transversed  by  an  aircraft  in  15  seconds  would  have 
to  take  into  account  2  a  (4.  6  seconds)  at  the  beginning  of  the  interval  and  2  a  (9.  2) 
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Figure  E-2.    Prediction  Time  Error  Due  to  Velocity  Uncertainties 


seconds  at  the  end  of  the  interval.    This  inaccuracy  in  prediction  results  in  almost 
doubling  the  time  for  which  a  link  (or  node)  must  be  reserved  and  illustrates  the 
difficulties  in  attempting  to  predict  beyond  30  seconds  in  the  future  to  any  degree 
of  accuracy  within  the  boundaries  of  the  Ground  Control  System. 


APPENDIX  F  -  AIRCRAFT  MOVEMENT  PROFILE  CHARACTERISTICS 
FOR  RUNWAY/TAXIWAY  CROSSING  CONTROL 


1.0    LANDING  CONSIDERATIONS 

Arriving  aircraft  may  be  considered  to  be  in  one  of  three  phases  while  handled  by 
the  Local  Controller.     These  are: 

1.  Tracking  Phase 

2.  Pretouchdown  Phase 

3.  Runway  Occupancy  Phase 

Figure  F-l  illustrates  these  phases  and  the  definitions  to  be  used  in  the  following 
discussion;  the  distance  parameter  "S"  is  taken  as  zero  at  runway  threshold  and 
negative  prior  to  this  point.  Since  the  distances  must  be  related  to  time  we  may 
note  that  representative  landing  speeds  range  from  125  mph  (183  fps)  for  the  737 
to  about  165  mph  (242  fps)  for  the  707  and  747. 

Considering  first  the  Tracking  Phase,  the  ARTS  computer  updates  aircraft  location 
every  4  seconds  and  displays  this  information  to  the  Local  Controller  until  the 
"track"  is  dropped.     This  occurs  at  slightly  different  times  for  various  runways; 
for  discussion  purposes  we  shall  use  a  value  of  S2  (the  track  drop  point)  equal  to 
7500  ft.    The  estimated  maximum  width  of  the  track  drop  interval  is  4  x  242  =  968  ft, 
i.e.  ,  approximately  ±500  ft  from  the  nominal  center.    The  "BRITE"  display  pro- 
vides half-mile  range  lines  separated  by  half-mile  spaces  as  a  scale  on  which  the 
aircraft  location  is  seen  during  the  Track  Phase.    If  the  controller  wished  (and  had 
the  available  time)  he  might  estimate  the  aircraft  positions  to  about  1/5  of  the  range 
line,  i.  e.  ,  to  a  precision  of  about  500  ft. 

The  Pretouchdown  Phase  occurs  over  the  distance  S2  +  S    where  S2  has  been  taken 
as  7500  ft.    The  distance  S    depends  upon  many  parameters;  average  values  of 
1000  ft      (Category  B  aircraft  landing  at  164  fps)  and  1500  feet    (Category  C  and 
D  aircraft  landing  at  202  and  237  fps,  respectively)  are  cited  in  FAA  Publication 
AC  150/5335- 1A.     With  S    +  S    ranging  from  8000  ft  to  9000  ft  the  Pretouchdown 
Phase  may  take  from  33  seconds  to  50  seconds  for  velocities  of  183  fps  and  242  fps. 


During  this  interval,  while  the  aircraft  is  1.  5  miles  to  3  miles  from  the  tower, 
the  Local  man  must  rely  solely  on  visual  observations  for  any  decision  he  may 
wish  to  reach. 

Following  "touchdown"  we  may  define  the  actual  Runway  Occupancy  Phase  which 
lasts  until  turnoff.     During  this  phase  substantial  aircraft  deceleration  must  take 
place.    The  amount  of  "braking"  and  the  time  at  which  it  is  applied  depends  upon 
the  location  and  type  of  "turnoffs",  surface  conditions,  aircraft  type,  actual  touch- 
down point,  etc.      Actual  measurements  on  210  aircraft  on  most  of  the  runways  at 
O'Hare  gave  average  values  of  time  from  threshold  to  turnoff  ranging  from  38 
seconds  to  52  seconds  depending  upon  the  runway  used  (standard  deviation  of  each 
runway  ranged  from  6  seconds  to  19  seconds).    Allowing  about  6  seconds  from 
threshold  to  "touchdown"  (1250  ft  ■*■  200  fps),  runway  occupancy  time  varies  from 
22  seconds  to  40  seconds. 

Observations  made  by  Peat,  Marwick  &  Mitchell  in  April  1973  on  a  small  number 
of  aircraft  at  other  airports  provided  the  following  results: 


No.  of 

R/W  Occupancy 

Deviation 

Airport 

Observations 

Time  (sees) 

(sees) 

TPA 

6 

43-68 

11.2 

Houston 

7 

46-75 

9.7 

New  Orleans 

13 

48-73 

8.  1 

These  wide  variations  in  runway  occupancy  may  increase  the  total  runway  crossing 
time  (including  delay  time). 

2.0    SIMPLE  THEORETICAL  BRAKING  MODEL 

Prediction  of  the  arrival  time  of  a  moving  object  at  a  point  on  its  trajectory  can  be 
made  based  upon  knowledge  of  its  present  position  and  velocity  in  conjunction  with 
assumptions  regarding  its  future  behavior.    These  assumptions  might  include  a 
constant  future  velocity  equal  to  that  at  the  measured  point.    The  predicted  arrival 


time,  or  "time-to-go"  would  then  be  conservative,  or  smaller,  than  would  actually 
be  experienced  by  an  aircraft,  for  example,  rolling  on  a  runway  and  influenced  by 
"drag"  and  frictional  components. 

Consider  a  moving  aircraft  with  constant  velocity,  V  ,  which  at  t  =  0  a  distance  D 
from  a  remote  point  (such  as  an  intersection). 


is  the  distance  traveled  by  the  aircraft  in  "t" 


D-S 
T   (t)  =  -rr-  is  the  minimum  predicted  "time-to-go",  or  time 


g 


go 


to  reach  D  based  on  V(t)  <  V  . 


is  the  "time-to-go"  at  t  = 


For  this  constant  velocity  case,  the  "time-to-go"  decreases  with  time  from  the  T 
point. 

A  landing  aircraft  will  apply  deceleration,  or  braking,  to  reduce  its  runway  occupancy 

time.    This  deceleration  rapidly  reduces  the  aircraft  velocity  and  therefore  increases 

T    as  will  be  shown  below.    While  the  shape  of  the  applied  deceleration  function  is 

variable  (dependent  upon  aircraft  type  and  pilot  actions)  we  shall  assume  a  constant 

deceleration  of  value  "a"  lasting  for  a  time  interval  t    and  starting  at  t  =  0  when 

v  =  v  .    We  then  have 
o 

v  =  v    -  at  ("a"  taken  as  positive  for  deceleration) 


The  above  relationships  hold  only  during  the  interval,  t   ,  during  which  the  decelera- 
tion is  applied.    The  range  of  values  of  the  several  parameters  are  as  follows: 

v    -  66  fps  (45  mph)  to  242  fps  (165  mph) 
o 

2 
a    -  0  to  12  fps     (about  0.4  g's) 

t-   -  0  to  6  seconds 

Assuming  an  initial  value  of  T      at  30  seconds  (for  example  D  =  7200  ft  and 

V    =  242  fps)  the  expression  for  T  (t)  may  be  approximated  below,  by  noting  that 

2 
the  maximum  value  of  the  "at  /2  V  "  term  is 
o 

12  (6)     *2  (66)  =  3.3  seconds 

which  is  small  compared  to  T      -  t. 
go 

Therefore 


*       S° 


T   (t)» 


This  equation  for  minimum  predicted  arrival  time  has  been  plotted  in  Figure  F-2 

for  a  constant  T      in  order  to  show  the  non-linear  deceleration  effects  of  the  a/v 
go  o 

ratio. 
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Figure  F-2.    Deceleration  Effects  on  Minimum  Predicted 
Arrival  Time 


Applying  the  above  to  a  specific  example  with  two  deceleration  phases  we  might 
have 

•  First  constant  velocity  phase 

v    -  200  fps 
o 

T      (at  end  =  35  sec.  i.e.,  D  =  7000  ft) 
go 

•  First  braking  phase 


v  (6  sec)  =  200  -  60  =  140  i 


_a_  _    10 

v     ~~  200  " 


.05(6) 

•  Second  Constant  Velocity  Phase  lasting  5  seconds 
T  (11)  =41-5  =  36  seconds 

•  Second  Braking  Phase 

2 
a    =  10  fps       t    =  6  sec 

Then 

V(17  sec. )  =  140  -  60  =  80  fps 

-=^  =  •071 

v        140 


1  -  .071(6) 


52.3  seconds 


The  results  of  the  above  example  are  plotted  in  Figure  F-3.    This  curve  of  minimum 
predicted  arrival  time,  T  (t),  could  be  applied  to  establishment  of  a  "denial"  window 
wherein  an  aircraft  at  the  intersection  would  not  be  permitted  to  cross.    If,  for  the 
above  example,  45  seconds  were  necessary  for  crossing  (including  response  time 
and  suitable  margins  for  safety)  the  duration  of  the  "denial"  window  (red  light)  would 
be  25  seconds  for  the  example  cited. 

3.0    EXPERIMENTAL  RESULTS 

To  further  examine  the  benefits  of  the  prediction  technique,  landing  profiles  were 
developed  (from  ASDE  films)  for  a  few  aircraft  arriving  at  runways  9R,  32L,   14R, 
and  27R.    The  position  vs  time  measurements  permitted  a  rough  estimate  of  velocity 
vs  time  to  be  developed;  sample  velocity  curves  are  given  in  Figures  F-4  and  F-5. 
The  differences  in  start  of  deceleration  as  well  as  the  magnitude  of  the  deceleration 
can  readily  be  seen. 

From  the  profile  data,  computations  of  minimum  predicted  intersection  arrival 
time,  T   ,  at  a  hypothetical  intersection  8000  ft  from  runway  threshold  were  com- 
puted as  a  function  of  time.    The  results  for  the  nine  aircraft  are  given  in  Fig- 
ures F-6  and  F-7. 

If  the  criteria  for  releasing  an  aircraft  across  the  intersection  is  selected  as  T 
>  45  seconds,  the  values  of  time  after  threshold  crossing  at  which  the  intersection 
could  be  activated  are  as  shown  in  the  first  columns  of  Table  F-l.    For  aircraft  8 
and  9  the  criteria  is  not  met  until  turnoff;  for  the  other  seven  aircraft  time  savings 
of  from  5  seconds  to  30  seconds  appear  possible. 

The  right  hand  column  of  the  table  shows  the  additional  "denial  time"  as  developed 
from  the  profile  existing  prior  to  runway  threshold  time.    The  average  of  the  total 
"denial"  window  (based  on  these  nine  aircraft  and  using  the  45  second  criteria)  is 
31  seconds. 

It  has  previously  been  noted  that  threshold  to  turnoff  interval  ranges  from  28  seconds 
to  46  seconds.    Using  an  average  of  37  seconds  (probably  low)  and  adding  the  average 
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Figure  F-3.    Sample  Aircraft  Deceleration  Process 
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Figure  F-6.    Minimum  Predicted  Intersection  Arrival  Time  - 
4  Aircraft 
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Figure  F-7.    Minimum  Predicted  Intersection  Arrival  Time  - 
5  Aircraft 


Table  F-l.    Experimental  Results 


Aircraft 
Number 

Permissible  Release  Time 

(Seconds  after  Runway 

Threshold) 

Additional  Denial  Time 

Prior  to  R/W 

Threshold  (seconds) 

1 

>30 

5.0 

2 

0 

0 

3 

12 

5.0 

4 

33  Estimate 

8.0 

5 

20 

9.0 

6 

28 

8.0 

7 

24 

4.0 

8 

Turnoff  at  35  sees 

4.0 

9 

Turnoff  at  40  sees 

8.0 

5.  7  Avg 

of  5.  7  seconds,  the  mean  denial  window  based  upon  visual  or  similar  observations 
of  a  clear  runway  for  release  of  a  crossing  aircraft  would  be  42.  7  seconds.  The 
increase  in  crossing  efficiency  (decrease  in  number  of  holds)  may  be  estimated 
by  considering  arrival  rates  of  30  and  36  per  hour  (for  one  side  of  the  O'Hare  air- 
port). The  average  inter-arrival  interval  of  120  seconds  and  100  seconds  may  be 
used  to  compute  the  percent  of  time  the  crossing  would  be  denied.    For  example, 

at  30  arrivals/hour  using  the  clear  runway  criteria,  the  crossing  would  be  un- 
42.7  . 


available  - 


120 


=  35. 5  percent  of  the  time. 


The  unavailability  of  the  crossing  for  the  two  operational  rates  and  two  decision- 
criteria  described  above  are  as  follows: 


Unavailability  of  Crossing  - 


Arrival  Rate 

30/hr 

36/hr 

Avg.    Denial 
Window  Duration 


Clear  Runway 
Criteria 


35.5% 
42.7% 


42.7  sec 


Predicted  Arrival 
Technique 


31.0% 
31  sec 


The  above  results  represent,  of  course,  only  a  limited  example  selected,  however, 
from  what  are  believed  to  be  representative  and  conservative  estimates.  Detailed 
studies  of  aircraft  deceleration  profiles  and  other  landing/turnoff  variables  should 
be  made  to  obtain  adequate  statistical  distributions. 


jy 


